Object-Oriented Modeling: A Roadmap

Gregor Engels Luuk Groenewegen

University of Paderborn Leiden University
Dept. of Computer Science LIACS, P.O. Box 9512
D-33095 Paderborn, Germany NL-2300 RA Leiden, The Netherlands
Tel.: +49-5251-60 3337 Tel.: +31-71-527 7139
[email protected] [email protected]

ABSTRACT system to be realized and forms an abstraction in two ways

Object-oriented modeling has become the de-facto standard (cf. Fig. 1). First, it abstracts from real world details which
in the early phases of a software development process are not relevant for the intended software system. Second, it
during the last decade. The current state-of-the-art is also abstracts from the implementation details and hence
dominated by the existence of the Unified Modeling precedes the actual implementation in a programming
Language (UML), the development of which has been language.
initiated and pushed by industry. The usefulness of an abstract system model was already
recognized in the 1970s, when structured methods were
This paper presents a list of requirements for an ideal
proposed as software development methods. These
object-oriented modeling language and compares it with
methods offered Entity-Relationship diagrams [5] to model
the achievements of UML and other object-oriented
the data aspect of a system, and data flow diagrams or
modeling approaches. This forms the base for the
functional decomposition techniques to model the
discussion of a roadmap for object-oriented modeling,
functional, behavioral aspect of a system. The main
which is structured according to a classification scheme of
six different themes, which are language-, model- or
process-related, respectively. Figure 1: Role of model within development process
Keywords
real
Object-oriented modeling, UML, profile, views, patterns,
world
frameworks, development process abstracts from
1. INTRODUCTION
It is one of the main objectives of the software engineering
model
discipline to support the complex and hence error-prone analyse abstracts from
software development task by offering sophisticated and design
concepts, languages, techniques, and tools to all
stakeholders involved. program
code
An important and nowadays commonly accepted approach
within software engineering is the usage of a software
development process model, where in particular the overall
software development task is separated into a series of drawbacks of these structured approaches were the often
dedicated subtasks. A substantial constituent of such a missing horizontal consistency between the data and
stepwise approach is the development of a system model. behavior part within the overall system model, and the
Such a model describes the requirements for the software vertical mismatch of concepts between the real world
domain and the model as well as between the model and the
implementation.
As a solution to these drawbacks, the concept of an
abstract data type, where data and behavior of objects are
closely coupled, became popular within the 1980s. This
concept then formed the base for the object-oriented
paradigm and for the development of a variety of new
object-oriented programming languages, database systems, map by identifying the main topics within the field of object-
as well as modeling approaches. oriented modeling as regions in a virtual landscape. In
Nowadays, the object-oriented paradigm has become the particular, section 4 presents a layered classification scheme
standard approach throughout the whole software of topics and illustrates existing drawbacks and approaches
development process. In particular, object-oriented to overcome them. Thus, this illustration is combined with
languages like C++ or Java have become the de facto a lot of references to existing promising approaches to
standard for programming. The same holds for the analysis overcome existing deficiencies. Obviously, such a
and design phases within a software development process, presentation can not be complete and is influenced by the
where object-oriented modeling approaches are becoming authors' background. But, the presented classification
more and more the standard ones. scheme will help to structure the road for research and
development in the field of object-oriented modeling within
The success of object-oriented modeling approaches was the next couple of years. The article closes with some
hindered in the beginning of the 90s due to the fact that conclusions in section 5 and a reference list as well as list of
surely more than fifty object-oriented modeling approaches related links to get further information.
claimed to be the right one. This so-called method war came
to an end by an industrial initiative, which pushed the 2. REQUIREMENTS
development of the meanwhile standardized object-oriented The starting point on the road map is the question: what do
modeling language UML (Unified Modeling Language) [4]. we expect, or rather require from an ideal object-oriented
modeling approach? So, we first discuss the requirements
But, despite the fact that it has been standardized, UML is
for an ideal object-oriented modeling approach. As object-
still a moving target. In particular, the above mentioned
oriented modeling aims at being central to the whole
horizontal and vertical inconsistencies are still to be
software engineering life cycle, the well-known software
resolved:
engineering principles and qualities, so expertly explained in
The currently offered language features of UML are [24], certainly apply.
not real world-specific, i.e., domain-specific enough,
In the particular context of object-orientation, however, we
since UML was designed as a general-purpose
can be substantially more specific about many of these
modeling language.
principles and qualities. So, we start studying object-
Parts of the context-sensitive syntax as well as the oriented modeling by reopening the discussion on software
semantics has not yet been stated formally, which engineering principles and qualities. The discussion
allows a lot of different interpretations of a UML concerns both the modeling language underlying the
model. approach and the steps taken in the approach. Thus, we
Furthermore, the (possibly automatic) transition from prepare the ground for the road map.
an UML model towards an implementation is still an What do we want? Basically we want object-oriented
open issue. modeling to be sufficiently user-friendly to all kinds of
Nevertheless, UML plays a very dominant role in the possible stakeholders. That is, for all clients of any model,
object-oriented modeling scene. It caused a lot of its relevant parts expressed in the modeling language, must
researchers as well as practitioners to orientate their work be understandable, must be clear even. For the modeler as
along UML issues and to focus on appropriate adjustments well as for all other persons involved in the modeling
of UML. These are, for example, domain-specific extensions activity, any model must be expressive, precise and clear as
of UML as, e.g., in the real-time domain, or semantic well. As these are properties for any model, they can be
definitions for (parts of ) UML. considered as properties of the modeling language in the
Also this article is influenced by the existence of UML. But, sense that the language should be such that it comprises
it is not intended to be an article on UML. The interested only models with the required properties.
reader is referred to corresponding web pages (see links at Precision immediately leads to the required qualities of
the end of the article) or to numerous articles in journals and correctness, reliability and robustness. Hence not only the
conference proceedings (e.g., [3, 22]). syntax, but also the semantics of the modeling language has
The structure and objective of this article are as follows: to be well defined, in order to make model review or even
model checking possible. Based on the semantics, at least
In section 2, requirements for an ideal object-oriented some mild forms of model review can be performed, e.g.
modeling language are presented. Section 3 summarizes the through prototyping, animation or other forms of validation.
state-of-the-art in the area of object-oriented modeling In addition, stricter forms of checking might be performed
languages. Due to the prominent role of UML, it is partially through verification, at least partial.
a brief survey on UML. Section 4 illustrates the still existing
shortcomings in the field of object-oriented modeling and A possible way towards user-friendliness as well as to
presents a structured view on the open issues in the field. correctness is indicated by another software engineering
An important contribution of this section is to draw a virtual principle, separation of concerns. By means of this
principle, components of a model can be formed each with a
certain role possibly reflecting existing roles from the and views. Then, the support also becomes apparent from
problem domain, views on a model can be defined each the smooth transition from informal requirements towards
conforming to the viewpoint of a certain class of users, formal model and from the smooth transition from formal
aspects of the model can be discriminated such as data, model towards programming code. In addition, effective
behavior, functionality, communication, security, timeliness. tool support can really improve the software engineering
In particular, the general software engineering principle of process. In particular, the consistency property of object-
separation of concerns combined with object-oriented oriented modeling with respect to the model parts, the views
modeling characteristics has turned out to be very useful. and the aspects can be fully exploited. This helps a modeler
What are these object-oriented characteristics? The basic to be aware of the consequences of all kinds of modeling
idea of object-orientation is the consequent application of choices in an early stage of the modeling.
the abstract data type concept, combining data and In view of the great number of different and varying
functionality. The abstract data type concept is applied in stakeholders of an object-oriented model, there is another
the context of the architecture of any object-oriented model. point to user-friendliness we want to stress. In the context
This architecture first of all advocates the distribution of of the recent globalization as global workbench and global
logically separated model parts, the classes. Secondly, it village, standardization of the object-oriented modeling
advocates their (re)integration. The integration actually language is absolutely necessary. As the homogeneity of
links the distributed classes into one model consisting of small and large model parts is to lead to integration and
(distributed) parts that are carefully kept consistent, e.g. via reuse that should be easier to perform because of the well-
the behavioral interfaces of the classes. In addition, the guarded consistency, it is crucial that every stakeholder
architecture has a number of other properties which are sticks to the standard. This is true within the same project,
appropriate. Not only is there consistency between the but also within the same problem domain. But on the other
model parts, but to a certain extent also aspects as data, hand there should be enough flexibility in the language to
behavior, functionality and communication are consistently allow for experiments with not (yet) standardized variants of
incorporated and integrated. or extensions to the language. Which balance between
Furthermore, apart from consistency between the parts, the standardization and nonconformity is wise, in order to give
object-oriented model architecture advocates homogeneity sufficient opportunity to investigate possible changes to
in the model parts: they all are classes. In line with Meyer's the language? An important guideline for incorporating any
pronouncement "Objects are the only modules" [36], form of anticipation of change in the language should be
compositions of classes in the form of modules or packages that homogeneity of as well as consistency between model
should result in something similar: the package or the parts is to be kept. As we expect, the guideline actually
aggregation itself should be a class. As a class, such a supports the anticipation of change, since it structures
package should unite all aspects of its constituting classes possible language extensions.
in a consistent manner, such that it can be consistently Summarizing, we come to the following requirements for an
integrated into the rest of the model. ideal object-oriented modeling language.
Through the properties of homogeneity and of consistency
with respect to its model parts, object-oriented modeling User-friendliness, leading to understandability and
gives a particular meaning to the software engineering precision.
principles of modularization and of separation of concerns. Precision leading to correctness as well as to
It should lead to full scalability of the modeling, since a richness of details, such as model parts, views and
whole model can be considered as one package, with the aspects.
properties of a class, which can be integrated in a larger
model in a consistent manner. Understandability together with separation of
concerns and modularization, combined with
Furthermore, also views on the model should lead to model object-orientation, leading to homogeneity of and
parts which as packages are homogeneous in form. This consistency between model parts, views and
should make consistent view integration considerably aspects.
easier.
The particular combination of the software engineering
principles separation of concerns and modularization with If we did not mention the other principles and qualities
the object-oriented properties of consistency and introduced in [24], it is not because we think they are less
homogeneity can be exploited to a far larger extent in the important. They are important. The particular combination,
embedding of object-oriented modeling in the overall however, of object-orientation with separation of concerns
development process. Then, the actual support in the and modularization gives rise to particular consequences
software engineering process becomes apparent from the with respect to these other principles and qualities, as we
incrementality in the modeling it allows in combination with will see in Section 4 where we discus future perspectives.
a well-guarded consistency between older and newer parts
But, before that we continue with a discussion in the next diagram to model the arrangement of run-time
section of where we are now. components on run-time resources such as a
processor, device, or memory.
3. STATE-OF-THE-ART
After having gathered the requirements for an ideal object- While all these sublanguages of UML are graphical or
oriented modeling approach, we will briefly summarize in diagrammatic languages, an additional textual language is
this section the current state-of-the-art in object-oriented provided by UML, to express static consistency constraints
modeling in industry and research. This forms the basis for on sets of objects and their interrelations. This is the object
identifying drawbacks and open issues to be investigated constraint language (OCL) [44].
within the next couple of years. In order to manage huge models, a purely syntactical
Object-oriented modeling in all areas is nowadays package concept is offered by UML, too. It allows to divide
dominated by the Unified Modeling Language (UML)[4]. a huge model into smaller parts, so-called packages, with
This language has been accepted as industrial standard in clearly defined dependency relations between them.
November 1997 by the OMG (Object Management Group). The main focus of the OMG standardization effort so far
UML was developed as solution to the so-called object- was an agreement on a commonly accepted standard
oriented method war, which rose up in the beginning of the notation for all these diagram types, while an agreement on
1990s, where more than fifty different object-oriented a formally defined and precise semantics was postponed to
modeling approaches could be identified in the software the next standardization phase. Currently, the semantics of
industry. Under the leadership of the three experienced UML language constructs is only defined in a textual,
object-oriented methodologists Grady Booch, Ivar informal way. By using a layered language definition
Jacobson, and James Rumbaugh, and with extensive approach, the abstract syntax of UML diagrams has been
feedback of a large industrial consortium, an agreement on defined precisely by the usage of a so-called metamodel.
one object-oriented modeling language and, in particular, on This is itself a UML class diagram together with OCL-
one concrete notation for language constructs was reached constraints and it defines the context-free as well as
in an incremental and iterative decision process. For today, context-sensitive syntax of all UML diagram types.
UML version 1.3 represents the currently accepted
Despite the definitely dominant role of UML, competing and
industrial standard [37].
extending approaches towards object-oriented modeling
UML was intended as a general purpose object-oriented exist in industry as well as in academia. Well-known
modeling language assembling variants of different already examples of these modeling approaches are the OPEN
existing modeling languages which are suited to model Modeling Language, OML [20], or the Business Object
certain aspects of a system. In particular, the following Notation, BON [38].
languages are part of UML:
In particular, domain-specific approaches have been
use case diagrams to model the main functionality of a developed in the past decades. Examples are modeling
system as well as the main involved actor roles. approaches
class / object diagrams to model all structural aspects for real-time and embedded systems (e.g. ROOM [40])
of a system. These diagrams originate from Entity-
for state-based, interactive systems (e.g. Statecharts
Relationship diagrams [5] and are useful to model the
[26]),
structure of single objects, their possible structural
relationships as well as the signature of operations. for reactive and concurrent systems as e.g. Petri Net-
based approaches [27] or logic-based approaches like
different forms of behavioral diagrams to model
OBLOG [41] or TROLL [31], or
dynamic aspects of a system. These comprise
for concurrent, collaborating systems (e.g. SOCCA
a variant of Harel's statecharts [26] for modeling
[14]).
system or object states and their possible
transitions, Beside being domain-specific, these approaches differ from
the current state of UML in that they often come along with
activity diagrams as dual interpretation of
a precisely defined semantics. A reason for this is that these
statecharts for modeling procedural control flow,
approaches are often centered upon one specific diagram
and
type, viewing all other diagram types as extensions of this
sequence diagrams as a variant of message basic type.
sequence charts (MSCs) [29] and so-called
These two drawbacks of being a general-purpose language
collaboration diagrams to model the interaction
and lacking a precise semantics have been identified by the
between objects over the time.
UML standardization groups and have led to establishing
two forms of implementation diagrams, i.e., the corresponding task groups and related RFPs (Request For
component diagram to model the concrete software Proposals) by the OMG (cf. [34]) to overcome these
units and their interrelations, and the deployment shortcomings. It has to be expected that further versions of
UML as well as proposals for domain-specific extensions 2.) model constituents: the model parts that reflect the way
(so-called profiles) will be developed and published within one wants to separate one's concerns;
the next years. 3.) model composition: grouping the constituents into some
Beside being too abstract in case of domain-specific integrated unity based on relationships as aggregation,
applications, the general-purpose nature of UML also refinement, etc.;
missed an appropriate process support for deploying the 4.) modeling process: support for the process of
various UML diagram types. This situation has been constructing a model;
improved in the meantime, as several development methods
have been proposed in the literature. Prominent examples 5.) model review: techniques to ensure the quality of the
are the Unified Process [30], the Catalysis approach [11], or built model and to verify expected and required properties
the approach for real-time applications in [10]. of the model;

Finally, a great variety of commercial software tools are 6.) embedding the modeling in the whole software
available on the market. Most of them are still under development process: consequences for the software life
development in the sense that they support only parts of cycle.
the complete UML, that they do not offer sufficient process The order of these themes exhibits some interesting
support, or that they are hard to integrate within an overall structure, too. Let us suppose for a - really very short -
software development environment. moment, we study the themes strictly subsequently. First,
we study a language as formalism. Then we study elements
4. PERSPECTIVES
- the constituents and their composition - from the
Based on the above discussion of requirements and of the
descriptions formulated in the language. Next we study how
state-of-the-art, we shall investigate the landscape of
to come up with such a description, followed by studying
drawbacks and open issues in order to find the road for
how to check such a description. Finally, we study
research and development tasks for the next couple of
integrating the last two processes into their umbrella
years.
software engineering process.
First, we start with structuring the landscape and
This is very similar to the (pre)history of software
identifying regions of related topics. Thus, by applying the
engineering: to develop programming languages, to identify
principle of separation of concerns to our own presentation,
basic program elements, to define the programming process,
we yield the following six regions illustrated as packages in
to define the testing process, to integrate the latter two
UML notation and interrelated by a dependency relation (cf.
processes into their umbrella business process, being the
Fig. 2):
software engineering process. In the past, when we still had
1.) language structure: the definition and architecture of an to learn the process of software engineering, the latter
object-oriented modeling language itself, ranging from core series of themes from programming language to process
elements to application-specific extensions; embedding were studied one after the other, spanning a
period of over forty years. In the case of object-oriented
Figure 2: Regions of the object-oriented modeling modeling languages, we can organize the study of themes
landscape from the regions in parallel, while being aware of the
structure these themes fit in. This can considerably reduce
modeling process
the time span of research, maybe ten years instead of forty.
(in-the-large)
To summarize, it is the structure of the themes that is crucial
for understanding the relevance of the topics to be studied.
Therefore, in the discussion below some of the topics will
modeling process be mainly illustrative for the structure in the grouping of the
model review topics. In such a case we will content ourselves with only a
(in-the-small)
very short description of the topic.
4.1 Language Structure
model
The classical basics of a language are its syntax and its
composition
semantics. From the ongoing research activities concerning
UML two important problems emerge. Whereas the syntax
of this has been precisely described by using a metamodel
model
approach, this does not hold for the semantics. When it
constituents
comes to describing the meaning of the various syntactic
language constructs, usually English is used with its
inherent informalities and ambiguities. The other problem is
language the large and complex scope of the language. An extra
structure complication are the built-in features for incorporating
anticipation of change into the language, such as Another point of study that seems interesting, is the binary
stereotypes, tagged values and constraints. On the one character of some relations between constituents. For
hand this makes UML an almost guaranteed part of any instance, actual calling of a method of an object is normally
future object-oriented modeling language. UML, so to say, done from one other object. This is the typical caller - callee
can serve as the starting point for such a future language. relation. Is this necessary? Could it be useful, even
On the other hand, the nature as well as the meaningful use clarifying, if the number of two participants in this relation
of these features still needs further study. could be generalized into some larger number. First results
Because of the highly complex nature of such an object- of the study of these so-called multi-methods can be found
oriented modeling language we propose to add a layered in [39]. This might result in new forms of dependency and
structure to the language (cf. Figure 3). This is in line with influence and therefore of consistency.
current work on UML 2.0 as well as of the precise UML
Figure 3: Language layers
group, where an improved layered architecture of the UML
is a major point of discussion [34, 18]. language
The first, innermost layer or shell contains the core
language. It contains the basic language elements of UML,
application-specific
its basic building blocks. It is to be a point of study which
extensions
language elements will belong to the core. Most probably,
classes, relationships, i.e., class diagrams, have to be put
there. Also one or two from the triple use cases, activity
domain-specific
diagrams, state machines, representing the more simple
extensions
behavior modeling elements, will belong to the core, and
may be even some form of interaction diagram will also
belong to it. Finally, also the constraint language OCL will modeling
belong to this core. It has to be discussed, what are useful, language
necessary criteria for a language element to belong to the
core. A possible criterion could be, whether the semantics
of that element is completely defined and can be expressed
core language
and understood in a relatively easy manner.
The second layer contains the other language elements
being the less basic elements of UML. It is an important
point of research and part of this second layer to The definition of the semantics of an object-oriented
investigate how the different sublanguages of an object- modeling language is a hard and difficult task due to the
oriented modeling language are interrelated. This holds for inherent divergence of the different sublanguages of a fully-
instance for the interrelation between statecharts and fledged object-oriented modeling language like UML.
interaction diagrams, but also the connection between OCL Currently, different approaches are investigated like
specifications and the remaining UML model [8]. operational ones based on state transition systems or graph
Furthermore, the concrete syntax of an object-oriented transformation systems, or denotational ones. In any case,
modeling language has to be studied. In particular, the role it is a fact that a precise and formal semantics is a
of so-called hybrid languages - combining textual and prerequisite for any type of model review and model
graphical notations - has to be investigated (cf. [1]), as it checking and of embedding the model into the overall
might not always be true that graphical (or textual, resp.,) software development process.
representations are more easily comprehensible for a The third layer (cf. Fig. 3) consists of the domain-specific
potential user. For instance, graphical representations for extensions to the language, so-called domain-specific
the OCL, so-called constraint diagrams, are currently profiles and domain-specific frameworks. Here, we see the
investigated as alternative for the originally proposed extensions to UML in the context of a particular domain. To
textual notation [32]. give an impression of such domains and domain-related
In addition, the completeness of an object-oriented ongoing activities, we mention the domains of real-time
modeling language has to be studied. This means whether applications [10, 40], multimedia applications [43], web
appropriate language features are offered for all applications [7] and last but not least the software
perspectives of a system to be modeled. For instance, for development process [30]. The profiles are formulated in
the description of what happens during execution, i.e., how terms of the UML´s extensibility mechanisms, i.e.,
object structures are rearranged and object values are stereotypes, tagged values and constraints.
changed, graph transformations as in [21] could be taken An alternative approach to yield a domain-specific
into account. adaptation of a modeling language is the usage of a
domain-specific framework. Frameworks are architectural
patterns, i.e., they form a partial model, which expresses 4.2 Model Constituents
common basic structures and behavior within a certain The constituents of a concrete model (cf. Figure 2) reflect
domain. They can be extended by refinement and the modeler's way of separating the various concerns seen
specialization to yield a complete model for a certain as relevant for the concrete situation to be modeled.
application. The usage of UML for describing a framework Consider the situation of an architect designing a prefab
for business processes has been studied, for instance, in house. Parts of the house are to be made in some factory,
[35]. As a framework is defined as an architectural pattern, and the parts have to be put together on the spot where the
we thus see patterns return as elements of our third layer. It final house has to be built. A part is a complete wall or floor
is intriguing to investigate in what sense and under what element, containing the (local) pipes and tubes for gas,
circumstances patterns (cf. [23]) can be an alternative to the water, central heating, the electricity wiring and such things
use of UML´s extensibility mechanisms. as radiators, windows, doors. So in this case, the
The fourth layer contains the application-specific architectural design of the house physically consists of the
extensions to the language on top of the domain-specific drawings of the prefab parts. When a potential buyer of
extensions from the previous layer. The prefaces as such a house wants to see a drawing of the house, he
discussed in [9] belong to this layer. Depending on the actually gets a series of interrelated drawings, one for each
concrete context of a certain application, so-called semantic floor. These drawing do not in the least reflect drawings of
variation points occurring in such a preface have to be the prefab parts the house is composed of, although the
fixed, thus pin-pointing the pragmatics for that application. floor representations are thoroughly consistent with these
There seems to be some similarity with the frameworks parts. Moreover, if the potential buyer wants to be
mentioned above, so on this level, too, we see the patterns completely informed about the central heating system, he
return. will also get a drawing on scale containing all heating-tubes,
radiators, the stove, and the thermostat. Also this drawing
In this subsection, we have proposed a shell-layered does not in the least reflect drawings of the prefab parts,
language structure. The innermost shell contains the most nor does it reflect all information from the floor
general elements, the outermost shell the least general ones. representations. But again, there is full consistency with the
As patterns cover the full range of recurring problems, other representations.
whether this is over all domains, or restricted to one domain
but over all applications, or just restricted to one type of Analogous to the prefab house, an object-oriented model
application, we see the patterns occur in three out of four has many constituents, which are different in nature. First of
shell layers. all, a model consists of the constituents it has been - really,
physically - made of: the classes, with their data, behavior,
It is very imaginable that the impact of the elements in the functionality, communication, and of relationships as class
domain-specific or the application-specific shell on the connectors. Also packages belong to the physically real
language support may vary in the course of time. For constituents of a model. These constituents exactly reflect
instance, there may be a shift in impact of a specific pattern how the model has been constructed, similar to drawings of
from the domain-specific shell towards a more general shell. the above prefab parts of the house. Second, a model also
As a concrete example, we mention the role of the has other representations. Such a representation is a
communicator in the Model-View-Communication-Controller different form the model takes, when represented depending
pattern [42], which may lead to new language features in the on a particular use of the model one has in mind. Not the
language shell or even the core shell, to express different model as it is, but as one can think of it, the model with its
alternatives of communication between objects in a more representative constituents. Examples of such different
explicit way than it is supported by currently available representations are views, subjects and patterns. They
language features. themselves consist of the same type of constituents,
Summarizing, we see the following four main open issues in classes and relationships, as the model physically does, but
the language region. differently represented, similar to the drawings of the floors
versus drawings of the various prefab parts. Third, the
Open issues in the Language region: classes actually combine things that, unless on metalevel,
are not to be represented as classes and relationships
language architecture (core vs. profiles)
themselves. Examples are data, behavior, functionality,
hybrid notations (textual vs. graphical) communication. They are aspects that are bound together in
completeness the various classes, similar to the above central heating
semantics system. The aspects are so to say woven into the classes
[33].
Where there are so many different components in a model,
the real ones, the representative ones as views and
patterns, and the aspects, the interrelations between the
components have to be carefully watched over. There is
really much consistency to take care of. Important parts of and for change. For instance, extending a model or a small
this consistency management issues have already been part of it with some other model(´s part) that has new or
studied, as, for instance, in the viewpoint approach [19], more sophisticated functionality, should be relatively easy
where consistency between different views could be kept and also well understood.
by an explicit consistency management. A different We see scalability into two directions, horizontal and
approach of an (automatic) integration of possibly vertical. Horizontal scalability consists of adding or
overlapping views or subjects into an overall model has removing model parts as classes, packages, patterns, views
been discussed in the view-based development approach of or aspects. Vertical scalability consists of refinement or its
[16], or the subject-oriented design technique of [6]. reverse aggregation.
The real model, the one with the real components, actually When, model parts are being put together in the horizontal
describes its own architecture, although probably from a direction, one has to perform the actual integration of these
logical point of view, and not so much from a hardware and parts with the already present ones. Not only in a syntactic
system software point of view. Therefore, further study of sense, but also in a functional, semantic sense. This means
the relation with architecture description languages (ADL) that we need composition techniques for the different types
seems promising in view of mutual usefulness of both of constituents. For instance, we need a better
approaches for each other [13]. Architectural patterns may understanding how to refine behavioral descriptions like
turn out to be important, so the above consistency insights statechart-based ones. A discussion on two different types
could be relevant for this situation, too. of statechart inheritance together with concrete
Patterns as a different kind of constituent of a model have construction rules can be found in [12].
been studied e.g. in [23]. Similar to views, also patterns are Horizontal compositionality might result in the requirement
to be composed with other patterns. Pattern integration to treat all constituents of a model as a semantic unit with a
should be such that mandatory or perhaps only desired or clear defined interface through which such a model part
optional consistency can be guaranteed. looks like a class. In particular, this might mean to lift
A third but different type of model constituent is the aspect packages from the syntactic level to the semantic level.
or feature. Aspects or features are not classes, but types of Scalability in the vertical direction is very often
general characteristics or concerns for the model as a whole, modularization, resp. more concrete either refinement or
see e.g. [33, 46]. Examples for aspects are communication, aggregation. In the case of refinement, an existing model
resource sharing, replication, distribution. Such an aspect part changes its content into a new, more detailed content,
normally is entangled, intertwined with everything else in but from the outside it still looks as before. So the old part is
the model. Small bits of the aspects can be found in many replaced by some more detailed part, for instance one class
different parts of the model. The parts are the classes, so is replaced by a whole group of cooperating classes. Such a
the classes bear small parts of the aspects. Further research group then is known as a module. The module replaces the
is required to shift the aspect-oriented from the old class, by representing itself to the rest of the model as if
programming level to the modeling level. Here, it has to be it is that class. The other way round is the grouping of a set
investigated which aspects can be specified separately and of already existing model parts, e.g. classes, into something
what are the interrelations between different aspects or new, the module. The module represents the set towards the
features (see e.g. [2] for an investigation on feature rest of the model. Quite often we want a module to look as
interactions). much as a class as possible. This is in line with the
Summarizing, we see the following open issues in the model aggregation concept, where a group of classes constitutes
constituents region: the aggregation class. Adapting to the type level, the above
cited remark of Meyer now becomes: Classes - instead of
Open issues in the Model Constituents region: objects - are the only modules. It has to be investigated
how class-like descriptions of certain modules or packages
modeling units and their interdependencies can be defined and eventually constructed, also with
views, subjects respect to non-structural aspects as behavior, functionality
aspects, features and communication.

patterns, frameworks Summarizing, we see the following open issues in the model
composition region:

4.3 Model Composition Open issues in the Model Composition region:

With so many model constituents around, one needs
scalability
flexibility in changing from a small number of constituents
to a large number and back, without straining the model horizontal / vertical composition techniques
elements and expressiveness too much. This is known as
scalability. Scalability has direct consequences for reuse
4.4 Modeling Process (in-the-Small) SOCCA [15], where based on purely sequential state
After having discussed constituents of object-oriented transition diagrams, used for both the visible behaviors and
models and requirements for having full scalability in a the hidden functionalities, new notions are defined for
model, we now discuss the process of developing such a specifying phases of behavior (temporary behavior
model. We see the following question to be crucial for the restrictions) and how to control these.
development process: how to take care, from the beginning,
of the coordination between all constituents, such that the
scalability requirements are met? As a matter of fact, in Figure 4: Model-View-Communication-Controller Pattern
UML many diagrams exist that relate to this coordination:
use cases, sequence diagrams, collaboration diagrams, state Controller View
diagrams, activity diagrams, deployment diagrams. A use
case specifies one behavioral scenario which among other
things addresses coordination. So does a sequence or
Communication
collaboration diagram, it also specifies one behavioral
scenario, but this scenario concentrates much stronger on
the interaction and hence on the coordination between
objects involved. State diagrams are based on statecharts,
so they specify behavior in terms of separate sequential
parts, the separate state transition diagrams. The Model
coordination between these sequential parts is explicitly
indicated. Activity diagrams have features from control flow
diagrams as well as from Petri nets. So they specify How to integrate new aspects, i.e., adding a new aspect to
coordination, too. In combination with so-called swimlanes, an existing model in a well-structured manner, is an open
the specification moreover expresses between which problem yet. Similar to the integration of the communication
classes the coordination takes place. A deployment aspect by some form of distribution over the classes, as it is
diagram, among other things, specifies whether some done in SOCCA [14], one can try to add a new aspect via
communication between its components exists, but it does local arrangements in the classes. The multi-dimensional
not express how the corresponding coordination is to approach of [45] might be of help here. It presents a
happen. (generic) framework by regarding the whole software
What is clearly lacking, is first the consistency between all development process as a path through a multi-dimensional
different coordination specifications, and second, a grid of aspects. Each node in the grid represents a
technique or approach for finding some reasonable composition of aspects. A concrete form of this framework
coordination specification. In our opinion, an explicit might help to better understand the process of developing a
coordination model is needed as submodel of an object- concrete model.
oriented model, together with an approach how to build Summarizing, we see the following main open issues in the
such a submodel and how to make and keep it consistent modeling process (in-the-small) region:
with the whole model. It might be a good idea to extend the
well-known Model-View-Controller (MVC) pattern to a so-
called Model-View-Communication-Controller (MVCC) Open issues in the Modeling Process (in-the-Small)
pattern [42] (cf. Figure 4). Here, the often implicit region:
communication and coordination becomes explicit and has consistency
to be handled by a separate component. This, is very much
coordination and communication
in line with current developments in middleware software,
where e.g. CORBA or DCOM components provide explicit
support for the communication part within a software
system. 4.5 Model Review
After, during or perhaps even before the actual
A different approach could be to see communication and its construction of the model, one certainly wants to evaluate
coordination as so fundamental for behavior and the quality of the model. In order to do this evaluation, one
functionality modeling that the object-oriented modeling at least needs full semantics of the modeling language.
language has to be extended or adapted with a separate
aspect for it (in addition to data, behavior and Two types of model review can be distinguished. These are
functionality). The new aspect should be such that all model animation or simulation techniques on the one hand,
communication and coordination is covered, that the aspect and analytical methods on the other hand.
is integrated with the already present aspects as data, As in the field of discrete event simulation, animation of
behavior and functionality, and that the specification of the the model is a very quick and intuitively very convincing
aspect is sufficiently scalable. This is the approach taken in way of telling both a designer and a user of the model
whether the model indeed reflects what one thinks it should requirements engineering phase and in the design phase. It
do. In combination with extensive what-if facilities this is not very common to speak about reverse engineering in
comes very close to testing the model. the context of this transformation, but animation of an
Animation, being a discrete event simulation, is a form of object-oriented model, or of whatever part of it, falls in this
validation, as only some example behaviors, some example category: through animation an informal visualization is
functionalities and some example communications are being presented of what the model or a part of it specifies. It is
imitated. It seems worthwhile to investigate under which even imaginable to reverse this form of reverse engineering.
extra conditions the animation can be replaced by a so- First an animation of the model-to-be is developed. As soon
called analytical computation model. That means, one can as every stakeholder is satisfied with it, the model can be
compute the behavior of the original model in a direct way, developed on the basis of the animations that actually play
instead of getting an estimation for it through simulation / the well-known role of simulation in information system
animation. Such computations are analogous to the various development.
computational analyses that can be performed in Petri nets. Back-end embedding addresses the transformation from
The extra conditions may concern assumptions concerning object-oriented model towards program code, code
the duration times of behavioral and of functional steps, or generation [17]. Here, it is has to be investigated, where
assumptions concerning the queuing mechanisms, or modeling stops and where programming starts. It has to be
assumptions concerning the composition of the model from understood, how much information, in particular concerning
certain logical parts. In case of an analytical computation functionality, has to still to be added to the program code. It
model, we have model verification with respect to the seems that the border between visual modeling and visual
results computed. This can be viewed as a sound basis for programming will be diminished in the near future or will
reasoning about the model. even disappear.
Due to the still missing complete semantics definition of Object-oriented modeling will become a solid basis for
object-oriented modeling languages, overall model checking round-trip engineering. When during the maintenance
support is still missing, too. Nevertheless, first results can phase some change is being proposed, this leads to the
be found in the literature, in particular, related to state situation where some newly developed model part has to be
machine or state transition systems (e.g., [25, 28]). In our integrated with an often large part of the original model.
opinion, this region in the landscape of object-oriented Hence, the above discussed scalability as well as horizontal
modeling languages deserves and will receive much more and vertical composition techniques can be of great help
attention in the near future. here. Again, animation as a kind of prototyping could be of
substantial help, too, in particular if the new scenario's can
Open issues in the Model Review region: be combined with the old scenario's.

animation / simulation techniques All issues discussed above have to be incorporated into an
overall software development process model and have to
analytical techniques be supported by appropriate software tools. For instance,
the role of animation, prototyping and model review have to
4.6 Embedding into the Development Process be appropriately integrated with all other model
In the above five regions, we can see some contours from development tasks.
the umbrella software engineering process. Examples of
these contours are: designing a model, reviewing a model, Open issues in the Modeling Process (in-the-Large)
integrating whatever model part into the rest of the model. region:
Designing a model has to be understood in a broad sense,
covering the whole lifecycle of model engineering. This front-end / back-end transformations
means concretely that the modeling language and its use round-trip engineering
have to be embedded in the software engineering lifecycle process models
process, covering all phases where some form of model
development is situated. Adopting for a moment the support tools
waterfall view with respect to software engineering, we .
speak about front-end embedding and of back-end
5. CONCLUSIONS
embedding of model design into the software lifecycle.
In this article, we have drawn the road map, i.e., the main
The front-end embedding addresses the transformation or open issues in the field of object-oriented modeling to be
translation from any informal description of the problem investigated within the next couple of years. As a base for
situation towards the object-oriented model. Often, an the presentation and future discussion, we introduced a
informal description is written in natural language, but also structured landscape consisting of six different regions.
video or other images can serve as such. This form of They address all perspectives of object-oriented modeling,
transformation occurs in the feasibility phase, in the i.e., the underlying language, the developed models, as well
as the development process. Within each region, we [8] St. Cook, A. Kleppe, R. Mitchell, J. Warmer, A. Wills:
identified concrete topics to be investigated and gave Defining the Context of OCL Expressions. In [22], 372-
references to some research results in order to illustrate 383.
possible ways to find solutions. [9] St. Cook, A. Kleppe, R. Mitchell, B. Rumpe, J. Warmer,
The whole discussion is biased towards two software A. Wills: Prefaces: Defining UML Family Members (in
engineering principles, which were identified in section 2 to preparation).
be the most crucial ones in the field of object-oriented [10] B. P. Douglas: Doing Hard Time - Developing Real-
modeling. These are user-friendliness of the modeling Time Systems with UML, Objects, Frameworks, and
approach and separation of concerns. As object-oriented Patterns, Addison-Wesley, 1999.
modeling is central to the whole software development
[11] D. D'Souza, A. Wills: Objects, Components, and
process, a great variety of stakeholders are dealing with the
model and the underlying language. Thus, first an intuitive Frameworks with UML - the Catalysis Approach.
and clear understanding of any model is an important Addison-Wesley, 1998.
prerequisite. Second, due to the complexity of the models to [12] J. Ebert, G. Engels: Structural and Behavioural Views on
be developed, in particular horizontal and vertical OMT-Classes. In E. Bertino, S. Urban (eds.):
structuring techniques are desperately needed. Proceedings International Symposium on Object-
The Unified Modeling Language (UML), currently playing a Oriented Methodologies and Systems (ISOOMS),
dominant role in the field, also influenced the presentation Palermo, Italy, September 21-22, 1994, LNCS 858,
and discussion within this article. The discussion on Springer, Berlin 1994, 142-157.
forthcoming versions of the UML will be a major task in the [13] A. Egyed, N. Medvidovic: Extending Architectural
near future in the field of object-oriented modeling. It is Representation in UML with View Integration. In [22],
obvious that a convincing solution to all open issues 2-16.
discussed above can only be reached if fundamental, [14] G. Engels, L.P.J. Groenewegen: SOCCA: Specifications
scientific research results will be combined in a synergetic of Coordinated and Cooperative Activities. In A.
way with industrial requirements and restrictions. Finkelstein, J. Kramer, B.A. Nuseibeh (eds.): Software
6. REFERENCES Process Modelling and Technology, Research Studies
[1] M. Andries, G. Engels: A Hybrid Query Language for Press, Taunton 1994, 71-102.
the Extended Entity Relationship Model. Journal of [15] G. Engels, L.P.J. Groenewegen, G. Kappel: Object-
Visual Languages and Computing, 7(3), September Oriented Specification of Coordinated Collaboration. In
1996, 321-352. N. Terashima, Ed. Altman: Proc. IFIP World Conference
[2] E. Astesiano, G. Reggio: A Discipline for Handling on IT Tools, 2-6 September 1996, Canberra, Australia.
Feature Interaction. In M. Broy, B. Rumpe (eds.): Chapman & Hall, London 1996, 437-449.
RTSE'97 - Workshop on "Requirements Targeting [16] G. Engels, R. Heckel, G. Taentzer, H. Ehrig: A Combined
Software and Systems Engineering", Technical Report Reference Model- and View-Based Approach to
TUM-I9807, April 1998, Technical University of System Specification. International Journal on Software
Munich, Germany, 1 - 22. Engineering and Knowledge Engineering, Vol. 7, No. 4,
[3] G. Booch (guest editor): UML in Action. CACM, Oct. December 1997, 457-477.
1999, 42(10). [17] G. Engels, R. Hücking, St. Sauer, A. Wagner: UML
[4] G. Booch, J. Rumbaugh, I. Jacobson: The Unified Collaboration Diagrams and Their Transformation to
Modeling Language User Guide. Addison-Wesley, Java. In [22], 473-484.
Reading, MA, 1999. [18] A. Evans, St. Kent: Core Meta-Modelling Semantics of
[5] P. Chen: The Entity-Relationship Model - Toward a UML: The pUML Approach. In [22], 140-155.
Unified View of Data. ACM Transactions on Database [19] A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein,
Systems, 1(1), 1976, 9-36. M. Goedicke: Viewpoints: a Framework for Integrating
[6] S. Clarke, W. Harrison, H. Ossher, P. Tarr: Subject- Multiple Perspectives in System Development.
Oriented Design: Towards Improved Alignment of International Journal of Software Engineering and
Requirements, Design and Code. In Proceedings of the Knowledge Engineering, 2(1), March 1992, 31 - 57.
OOPSLA '99, Denver, CO, USA, Nov. 1 - 5, 1999, ACM, [20] D. Firesmith, B. Henderson-Sellers, I. Graham: OPEN
New York, 1999, 325 - 339. Modeling Language (OML) Reference Manual,
[7] J. Conallen: Modeling Web Application Architectures Cambridge University Press, New York, 1998.
with UML, CACM, October 1999, 42(10), 63 -70. [21] T. Fischer, J. Niere, L. Torunski, A. Zündorf: Story
Diagrams: A New Graph Grammar Language based on
the Unified Modeling Language and Java. In H. Ehrig,
 G. Engels, H.-J. Kreowski, G. Rozenberg (eds.): Proc. of [36] B. Meyer: Object-Oriented Software Construction,
the 6th Intern. Workshop on Theory and Application of Prentice Hall, 1997.
Graph Transformation. Paderborn, November 1998, [37] Object Management Group. OMG Unified Modeling
LNCS 1764, Springer , Berlin, 2000. Language Specification, Version 1.3. June 1999.
[22] R. France, B. Rumpe (eds.): <<UML>>'99 - The Unified [38] R. F. Paige, J. S. Ostroff: A Comparison of the Business
Modeling Language, Beyond the Standard. Second Object Notation and the Unified Modeling Language.
Intern. Conference. Fort Collins, CO, October 28-30, In [22], 67-82.
1999. LNCS 1723, Springer, 1999.
[39] M. Schrefl, G. Kappel: Cooperation Contracts. In T. J.
[23] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Theorey (ed.): Proc. of the 10th Intern. Conf. on the ER
Patterns. Addison-Wesley, Reading, MA, 1995. Approach, October 1991, 285-307.
[24] C. Ghezzi, M. Jazayeri, D. Mandrioli: Fundamentals of [40] B. Selic, G. Gullekson, P. Ward: Real-Time Object-
Software Engineering. Prentice-Hall Intern, 1991. Oriented Modeling. Wiley, 1994.
[25] D. Giannakopoulou, J. Magee, J. Kramer: Checking [41] A. Sernadas, C. Sernadas, H.-D. Ehrich: Object-Oriented
Progress with Action Priority: Is it Fair? In O. Specification of Databases: An Algebraic Approach. In
Nierstrasz, M. Lemoine (eds.): Proc. ESEC/FSE '99, P. M. Stoecker, W. Kent (eds.): Proc. 13th Intern. Conf.
Toulouse, France, Sept. 1999, LNCS 1687, Springer, on Very Large Databases VLDB'87, VLDB End. Press,
Berlin, 1999, 511-527. Saratoga (CA), 1987, 107-116.
[26] D. Harel: Statecharts: A Visual Formalism for Complex [42] St. Sauer, G. Engels: MVC-Based Modeling Support for
Systems. Science of Comp. Prog., 8 (July 1987), 231-274. Embedded Real-Time Systems. In P. Hofmann, A.
[27] K. M. van Hee: Information Systems Engineering: A Schürr (eds.): OMER Workshop Proceedings, 28-29
Formal Approach. Cambridge Univ. Press, Cambridge, May, 1999, Herrsching (Germany), University of the
UK, 1994. German Federal Armed Forces, Munich, Technical
[28] C. L. Heitmeyer, R. D. Jeffords, B. G. Labaw: Automated Report 1999-01, May 1999, 11-14.
Consistency Checking of Requirements Specifications. [43] St. Sauer, G. Engels: Extending UML for Modeling of
In ACM TOSEM, 5(3), July 1996, 231-261. Multimedia Applications. In M. Hirakawa, P. Mussio
[29] ITU-TS Recommendation Z.120: Message Sequence (eds.): Proc. 1999 IEEE Symposium on Visual
Chart (MSC). ITU-TS, Geneva, 1996. Languages, September 13-16, 1999, Tokyo, Japan. IEEE
Computer Society 1999, 80-87.
[30] I. Jacobson, G. Booch, J. Rumbaugh: The Unified
Software Development Process, Addison-Wesley, [44] J. Warmer, A. Kleppe: The Object Constraint Language:
Reading, 1999. Precise Modeling with UML. Addison-Wesley,
Reading, MA, 1998.
[31] R. Jungclaus, G. Saake, T. Hartmann, C. Sernadas:
TROLL - A Language for Object-Oriented Specification [45] A. Zamperoni: GRIDS - GRaph-Based Integrated
of Information Systems. ACM Trans. on Information Development of Software: Integrating Different
Systems, 14(2), April 1996, 175-211. Perspectives of Software Engineering. In Proc. of the
18th Intern. Conf. on Software Engineering, March
[32] St. Kent, J. Howse: Mixing Visual and Textual 1996, Berlin, Germany, IEEE Computer Society Press,
Constraint Languages. In [22], 384 - 398. 1996, 48-59.
[33] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. [46] P. Zave: Feature Interactions and Formal Specifications
Lopes, J.-M. Loingtier, J. Irwin: Aspect-Oriented in Telecommunications. Computer, 26(8), 1993, 20-29.
Programming. In Proceedings of ECOOP'97, LNCS 1241,
Springer, 1997. 7. LINKS
www.omg.org - OMG home page
[34] C. Kobryn: UML 2001: A Standardization Odyssey.
CACM, 42(10), October 1999, 29-37. www.cs.york.ac.uk/puml - precise UML group
[35] G. Larsen: Designing Component-Based Frameworks www.rational.com/uml/index.jtmpl - UML literature
using Patterns in the UML. CACM, 42(10), October uml.shl.com - UML RTF home page
1999, 38-45.