A Summary of the ER'97 Workshop on
Behavioral Modeling

-- First Draft --

*Stephen W. Liddle, †Stephen W. Clyde, and ‡Scott N. Woodfield

*School of Accountancy and Information Systems, Brigham Young University
†Department of Computer Science, Utah State University
‡Department of Computer Science, Brigham Young University

This summary is available in several formats (to download, you might need to hold down the SHIFT key while you click): NOTE:  The HTML version of the summary is no longer the most current. The PDF and Word documents have been updated.

Here is the gzipped Springer-Verlag style guide (48KB).



Abstract

The ER'97 Workshop on Behavioral Modeling was held to consider the questions of what constitutes a "good" behavioral model, and assuming we have such a "good" behavioral model, what issues related to design transformations we should explore. This very international workshop included interesting and high-quality papers on both of these topics. The proceedings are available electronically through the World-Wide Web [10]. This paper summarizes the contributions of the Behavioral Modeling workshop and suggests directions for future research in behavioral modeling.



Introduction

Conceptual models are not just for databases any more. From its genesis in data modeling, the field of conceptual modeling has broadened to include behavioral constructs. The advent of technologies such as object orientation, active databases, triggers in relational databases, workflow systems, and so forth has placed greater emphasis on the need to model behavioral aspects of systems in addition to structural aspects. The literature reflects an increasing interest in conceptual models that cover both system structure and system behavior.

The problem of how to design a database system based on a semantic data model is well understood. The focus of traditional design is on issues such as constraint satisfaction, information redundancy, access times, etc. We apply well-studied information-preserving transformations (such as normalization or denormalization) to arrive at a database with the characteristics we desire. However, when we add behavior to the conceptual model, we introduce additional design challenges that are less well understood, such as controlling the amount of concurrency, optimizing communications between active components, ensuring correct synchronization of active components, satisfying real-time constraints, etc.

Researchers are devoting increasingly more energy to the problems of behavioral modeling in conjunction with traditional conceptual data modeling. Behavioral modeling is not new, but its tighter integration with traditional conceptual modeling has opened new questions and opportunities. ER'97 provided an ideal forum for gathering interested researchers to discuss challenges and progress, and to share ideas in this area.

On November 6 and 7, 1997, we held the ER'97 Workshop on Behavioral Models and Design Transformations: Issues and Opportunities in Conceptual Modeling, on UCLA campus in Los Angeles, California [10]. In the present paper we summarize the context and contributions of this workshop and point to directions for further useful research in the area of behavioral modeling.

The goal of the Behavioral Modeling workshop was to better understand theoretical aspects of behavioral models and use that understanding to suggest transformations that would be helpful in the design of active systems. We issues two major questions in our call for participation:

  1. What constitutes a "good" behavioral model?
  2. Given a "good" behavioral model, what issues related to design transformations should we explore so that our understanding of behavioral design will be as good as our understanding of more traditional structural design?

In our call for participation, we suggested the following topics related to the first question:

  • What are the essential characteristics of a behavioral model?
    • How close to the "real world" must a behavioral model be?
    • Is intra-object concurrency necessary or desirable?
    • Should the basic unit of behavioral transition be instantaneous?

  • How do we formally compare different behavioral models?
    • How do we measure power in a behavioral model?
    • Is computational completeness adequate?
    • When does one model subsume another?
    • Is a formal definition necessary or desirable?
    • Are there issues of notational expressiveness we should consider?

And we suggested the following topics related to question 2:

  • What are the desirable properties of a behavioral model design?
  • Are there useful canonical/normal forms for behavioral models?
  • Can we identify any meaningful behavior patterns that seem to recur frequently?
  • How do we measure quality in a behavioral model?
  • How do interface definitions impact the quality of a behavioral model?
  • What design transformations are necessary or desirable?
  • How do we guarantee information preservation in our transformations?
  • Should behavioral design be independent of the implementation platform?
    • Are there useful design transformations that are platform independent?
    • Are there useful design transformations that are platform dependent?
    • Should design assume complete independence from the eventual implementation platform, should it be totally dependent on the platform, or should we use something in between?

  • How does the inclusion of behavior in the conceptual model impact structural aspects of the model?
    • Are there subtle interactions between structural and behavioral constructs that we need to consider?
    • Are the transformations used in the absence of behavioral constructs still information preserving and otherwise effective in the presence of behavioral constructs?

  • How do designers know when a particular design is "done"? Can this question only be answered on a project-by-project basis, or even worse, must it be answered on a module-by-module basis?

We determined that issues related to actual implementation and specific methodology was well beyond the scope of our workshop. We would only address issues tied directly to conceptual modeling and conceptual design. This is the context in which the Behavioral Modeling workshop was created.

It turned out that the majority of our focus was on question 1, as the workshop participants felt we were not entirely ready to answer the second question. However, we made progress in both areas. We were pleased with the quality of submitted papers and actual presentations. There was an enjoyable, open atmosphere with considerable discussion.

We now summarize the workshop papers in the order they were presented. We conclude with a section on research questions that merit further study.



A Framework for Assessing Database Quality

John Hoxmeier presented a framework for assessing database quality [6]. This paper addressed aspects of both of the workshop topics. In order to agree on what constitutes a good behavioral model, we first need to understand the parameters that allow us to compare behavioral models.

Hoxmeier proposes that the application of a quality process does not necessarily ensure that a quality system will result. That is, a system could have high "data quality" without also exhibiting good "semantic or cognitive fidelity." A truly effective system would exhibit good characteristics along this added dimension. In this context, Hoxmeier's contribution is to extend a previous hierarchical framework for database quality measurement with behavioral considerations. He builds on the work of a number of groups who are interested in database quality assessment.

Hoxmeier's four primary dimensions of database quality include the already well accepted dimensions of data and process quality, and the newly proposed dimensions of semantics and behavior quality. In his paper he presents a description of each of these four quality dimensions.

Hoxmeier concludes that database quality assessment is critical to modern information-heavy organizations, and that we need a combination of quantitative and qualitative measurements to effectively assess database quality. Moreover, the inclusion of behavioral aspects in database quality assessment is imperative to forming an accurate assessment.



Behavioral Model Quality and Transformation

In his position statement, Martin Gogolla outlined a proposal for understanding and assessing the quality of design transformations [5]. He assumed that design would be done in successive steps (transformations) where the degree of detail and closeness to an actual implementation would increase with each transformation. With each transformation, relevant properties of the conceptual model should be preserved.

Gogolla advocates using an object specification language that is formal and hence clear enough for measured comparison of behavioral and structural aspects of a conceptual model. His research group has developed TROLL light as an illustration of such a language.

Gogolla analyzed the characteristics of TROLL light with respect to the two questions of this workshop, namely, what constitutes quality in a behavioral model, and what design transformations should we explore.

There was a high degree of group participation and discussion during Gogolla's presentation. Several proposals were discussed:

  • two-way transformations are superior to one-way transformations
  • quality could be measured in terms of the amount of implementation detail introduced by a transformation
  • transformations should be relatively uniform in scope


Dynamic Dialog Management

Bernhard Thalheim presented ongoing work (with W. Clauss and J. Lewerenz) that involves a new way of modeling and developing database systems for relatively naïve users based on the idea of dialog design [2]. Their research context is data warehousing. Thalheim proposed that instead of "behavioral" modeling we should be considering "dialog" modeling. Dialogs constitute a possible foundation for integrating database development along several dimensions, including static/dynamic, global/local, and architectural layers (or steps in the system lifecycle).

Many of the ideas developed in structural database design can be transferred to behavioral database design. The relationship between a "schema" and a "view instance" is analogous to the relationship between a "behavior definition" and a "dialog instance." Intuitively, a "dialog" is a "behavioral view." A dialog is the specification of how actors use database views to perform various activities within a system. In this sense, a dialog is much like a "use case" [7].

Thalheim et. al. take the point of view that whereas schema is the definition of possible database states, behavior is the definition of possible update operations that can transform one state into another. Dialogs integrate both of these ideas by showing how views (representing schema) are applied within the context of actual processes (representing system behavior).

When taking a dialog approach, it is no longer sufficient to focus merely on schema design. Instead, a structure-process codesign approach is more appropriate. That is, dialogs must be designed in conjunction with processes and views, because they present the end-user with access both to data and functions of the system. In analogy with theatrical production, the abstraction layers for dialog specification include idea (motivation), story, scenario, script, and production. Thalheim proposes that dialogs are appropriate for use at each of these layers, unifying the conceptual model used in specification, design, and implementation.

The dialog approach was demonstrated in the development of an information service based on a 25-line by 60-character display that is as easy to use as a television. This system is used to perform services such as buying theater tickets and reserving tables at restaurants. Open problems include the creation of a suitable dialog cooperation model (how do/should dialogs interact with one another) and the development of adequate dialog management tools.

Thalheim also identified a number of impedance mismatches in conceptual modeling and database design that relate to the topics of this workshop. In various ways, the dialog approach addresses these mismatches.

  • abstraction level
  • structure/process
  • structure/semantics
  • function/behavior
  • interface/DB schema
  • process/workflow
  • CASE tool (lack of interoperability)
    • different specification languages
    • different treatment of semantics & meaning
    • user needs aren't being satisfied


On the Quality of Conceptual Models

Harmen van den Berg presented a paper in which he and W.B. Teeuw propose general quality criteria for conceptual models, and based on those general criteria propose more specific criteria for evaluating behavior models [14]. Their work is done within the framework of the "Testbed" project in the context of telecommunications applications.

Others have proposed three kinds of conceptual model quality:

  • Semantic quality — degree of correspondence between a conceptual model and the real world.
  • Syntactic quality — degree of correspondence between a conceptual model and its representation.
  • Pragmatic quality — degree of correspondence between a conceptual model and its interpretation (degree to which model is understood).

Van den Berg proposes six general quality criteria:

  • Completeness — constructs are sufficient to capture essential aspects of the real world.
  • Inherence or propriety — constructs do not model derived features, only essential features.
  • Clarity — the conceptual model is understandable by designers.
  • Consistency — constructs do not conflict, are not ambiguous, and are parsimonious (a special case of inherence).
  • Orthogonality or modularity — the independence/dependence of model constructs is the same as the independence/dependence of corresponding real-world aspects.
  • Generality — model constructs are independent from applications and application domains.

The first three criteria correspond to external quality, and the last three to internal quality. Based on these criteria, van den Berg proposes a four-dimensional framework for evaluating models and tools for business process reengineering (BPR). These dimensions are functionality (expressiveness, abstractions, compositions, formal/methodological support, relevance of concepts, etc.), ease of use (accessibility, usability, adaptability, openness, etc.), BPR trajectory (which BPR phases are supported), and general (e.g., tool price, customer support).

Finally, van den Berg presented an example within the Testbed environment, illustrating how Testbed fits within the specified quality framework. He indicated that a bit more than half a dozen cases per year are being tested in actual practice with Testbed.



Behavioral Design Issues in a Distributed Environment

Stephen Clyde presented a position paper on problems that need to be addressed when designing the behavior of distributed systems [3]. Real-world distributed systems exhibit several important characteristics that distinguish them from centralized solutions:

  • Concurrency — real objects act simultaneously, but centralized systems only simulate concurrency.
  • Partial failure — independent objects can fail independently without causing system-wide failure, but centralized systems usually treat failure as an all-or-nothing condition.
  • Dynamic, incremental change — real-world systems are not completely shut down to accommodate change; instead, they are modified dynamically.

In spite of the correspondence between the characteristics of real-world systems and distributed systems, it is not true that a good conceptual model of a real-world system translates directly into a good design for a distributed system. As a principle, it is a good idea to minimize conceptual distances between steps in the system development lifecycle. However, numerous issues work to increase conceptual distance:

  • Complex mappings — analysis and design concepts are not one-to-one.
  • Fragmented behavior — a software object may only represent a portion of the behavior of a corresponding analysis object. Many fragments may correspond to portions of an analysis object.
  • Object distribution — physical distribution in the real world may not correspond to the best distribution of software objects.
  • Emergent communications — software objects need to communicate for reasons different than those defined in the analysis model (e.g., for replica management, transaction synchronization, name resolution).
  • Emergent resource sharing — software objects may share resources for convenience of implementation, not because those resources are actually shared in the analysis model.
  • Transparency — attempts to shield users from issues of actual object/service location, replication, migration, etc. further transform the software design so it is less like the analysis model.

Clyde concludes that distributed systems design is unnecessarily complex because current conceptual models do not support the right abstractions, and that if we work on defining correct abstractions, we can minimize conceptual distances and hence also design complexity. He proposes that we develop the following abstractions for

  • mapping software objects to analysis objects,
  • describing object fragmentation, especially for behavior,
  • specializing objects and object fragments without violating inherited semantics,
  • specifying and constraining object distribution, replication, and migration,
  • dealing with emergent communications and resource sharing,
  • and for patterns/idioms that help achieve transparency and other desirable properties.


Integration of Behavior Models

Heinz Frank presented a paper (written with J. Eder) describing algorithms for view integration when the conceptual model includes behavior [4]. View integration is a very effective approach for developing models — start with views from many different users and then integrate them. However, traditional view integration techniques deal with structural views. We need new approaches for views that include behavior. Frank and Eder's approach to view integration has two phases: static-model integration and dynamic-model integration. The former proceeds as usual, while the latter is the topic of Frank's paper.

Dynamic-model integration is divided further into three steps. First, the dynamic model is formalized by describing ranges of states and constraints on those ranges. For example, given a library, a book might be in the "available" state. If so, we require that the book's "status" attribute represent "in the library" and that its "reserved" attribute be "false".

The next step is integration-in-the-large, where an integration plan is developed. The goal is to minimize integration effort. An integration plan consists of integration operators, ICons and IMix (described in the paper), together with the models to which they are applied. To generate the integration plan, we first determine relationships that hold between different dynamic views (possibilities include parallel, disjoint, alternative, consecutive and mixed). From this, we construct a relationship graph and then use a set of heuristics to generate the actual integration plan. Mixed relationships (where fragments of both behavior specifications must be combined in the integrated type) require the most work, and are integrated as soon as possible.

The last step is integration-in-the-small, where we perform the actual integration by executing the integration plan. An example based on a library system is provided in the paper. Dynamic-model integration will be important as behavior becomes increasingly common in conceptual models. This automated approach to integration is a useful contribution.

 



A Comparison of Workflow Metamodels

Munindar Singh presented a paper (written with Y. Lei) comparing different metamodels for workflow modeling [8]. Singh and Lei's goal is to improve the level of conceptual modeling applied to workflow problems. As a fairly young field, much effort has been invested in improving tools and techniques for workflow, but less effort has been spent on conceptual modeling concepts. This paper presents metamodels for five common workflow approaches, defines evaluation criteria for workflow conceptual models, and uses these criteria to compare different approaches based on the metamodels.

The workshop participants observed that in a state-transition diagram (like that presented in Frank's work), work (or behavior) is accomplished in transitions. In contrast, in a workflow situation, work is accomplished in states. Thus, there is still a need for discussion on how best to model behavior (or if there is no "best", at least how to model behavior canonically).

Singh demonstrated how to study and understand existing workflow approaches. Using his metamodels, he is able to compare the salient features of different approaches. Having a basis for comparison, we can now improve our models formally and systematically. Singh believes that we will see more formal methodologies and also greater integration with database systems as workflow technology evolves. He also sees naturally decentralized models as a consequence of developing these metamodels. Finally, he predicts that the agent metaphor will be increasingly important in workflow. It was apparent to the workshop participants that workflow modeling is a significant area where behavioral issues arise. Future conceptual models need to support workflow techniques.



An Infological Perspective on Expressiveness

Bjorn Lundell presented a paper (written with B. Lings) on how the expressiveness of diagramming techniques can impact the use of conceptual models of behavior within an organization [11]. To do so, Lundell first places conceptual behavior modeling within the broader context of IS development, and then he describes how an "infological perspective" helps us improve the utility of behavioral conceptual models.

Lundell identifies two main problems. (1) An enhanced ER model extended to support behavior usually does so at the cost of significant added complexity in the resulting diagrams. This complexity is a barrier to use. (2) Instead of enhancing a conceptual model, we may use distinct models at the conceptual level to capture behavior. But when we do so, the number of interrelationships that must be maintained between related concepts in different models increases exponentially with the number of models used.

Traceability between behavioral models and other high-level conceptual models is very important, and Lundell observes that a repository should be used to capture this complex information. Once a model is in such a repository, the problem becomes one of extracting the information in appropriate views that are sufficiently expressive for the purpose at hand. Given a repository, then, we next need to develop appropriately expressive graphical view notations. But how do we measure expressiveness?

The "infological equation" states that information (I) is a function not only of data (D), but also the user's existing knowledge (S) and time (t) available for interpretation (that is, I = i(D, S, t)). Lundell proposes that expressiveness be measured in terms of the infological I. This implies that we cannot merely take a quantitative approach to measuring expressiveness — we must also use qualitative techniques to account for the subjectivity present in the infological equation. Lundell concludes with the observation that we need to consider systems development as a social process that involves various levels of participants. As such, Lundell proposes that we should apply the social sciences to our conceptual modeling methodologies.



Modeling Temporal Behavior Conceptually

Chiyaba Njovu presented a paper (written with T.W. Lawson) on modeling temporal behavior in the context of the object-oriented (OO) paradigm common to OMT, Syntropy, and similar OO approaches [13]. Typically, these OO models do not directly support temporal relationships, which are vital in real-world situations. Njovu's contribution is to propose extensions (specifically, to the Syntropy model) that support temporal relationships, memories of event occurrences, and object histories.

This workshop was particularly interested in extensions to Syntropy's dynamic model. Behavioral models are fundamentally interested in temporal aspects of a system, addressing the issue of how a system changes over time.

Njovu presented three temporal concepts: time points, durations, and intervals. Further, he showed how these concepts can be combined as elements in a timeline (a temporal aggregate). Finally, he distinguished between the notions of "valid time" (when an event occurs in the real world), and "transaction time" (when the corresponding event is recorded in the automated system). Njovu's extensions to Syntropy are based on these elements.

Syntropy uses the statechart abstraction to represent object behavior. However, statecharts fail to represent (1) the difference between events and "memories of events", and (2) the fact that some object types need memories of all its states (Njovu used the example of a loan system to illustrate this). The element that is missing from typical models is a timeline of what has occurred during an objects lifetime.

Njovu proposes that we support temporality by adding "temporal qualification" to the associations linking object types and state types. Temporal information (such as the time point, duration, or interval) about associations thus qualified can be maintained automatically by the system, thus relieving developers of the burden of working around the system to capture such information.



Events as Information Objects and Change Agents

Lars Bækgaard presented a paper describing how behavior can be modeled as events that are both "information objects" and "change agents" [1]. An event modeled as an information object is like a traditional entity that has attributes and can be queried. An event modeled as a change agent is comparable to an executable transaction schema.

Bækgaard first described how events can be modeled as information objects, augmenting a typical semantic data model with the concept "event set", which is like an entity set that contains event entities. A primary difference between entities and events is that events exist at a point in time, while entities exist over a time interval. Each event entity is always associated with a time attribute to represent the event execution time. Events as information objects can profitably be used for constraint specification, for example to constrain possible state transitions in which an entity may participate.

As change agents, events can be used to specify how a system behaves when events occur. Event specifications have the form EVENT <event signal> DO <command list>. Bækgaard described two possible commands that can be used in a command list, including TELL and UNTELL (for inserting and removing information from the database, respectively). Both commands have a WHERE clause describing the set of data to be inserted or removed.

Bækgaard next described how to specify event patterns, and he concluded with a discussion of how this approach compares to object oriented techniques. He identified several problems with traditional OO when applied to databases. For example, strong OO encapsulation forces the distribution of behavioral specifications associated with an event. Bækgaard concluded with the observation that traditional OO is not well suited for symmetric modeling of events as information objects and change agents.



Mismatches between Models and Implementation Environments

Scott Woodfield described problems with the relationship between conceptual models and implementation environments [15]. To minimize expensive, early errors in software development, we use conceptual models that are moving increasingly closer to reality and farther from computer implementation environments. But as we move closer to natural forms, we introduce conceptual mismatches (often called "impedance mismatches") between analysis models and implementation languages. In this paper, Woodfield describes eight specific problems associated with transforming an object-oriented conceptual analysis model into an implementation:

  • Persistence — OO conceptual models assume persistence, but OO programming languages do not.
  • Classes — in a conceptual model, classes usually have an extent that can be queried, and objects can migrate from class to class. In an implementation environment this is usually not the case.
  • Relations — implementation environments usually do not have relations, only attributes.
  • Generalization/Specialization — conceptual models use "is-a" semantics, while OO languages use inheritance. There are major differences between these two ideas, and we lose a great deal of the meaning of generalization/specialization when we restrict ourselves to inheritance.
  • Active Objects — OO conceptual models assume that objects can be active, but OO languages assume passive, invocation-driven behavior with an assumption of uniform service availability.
  • Concurrency — both inter- and intra-object concurrency is assumed at the conceptual level, but implementation environments generally support a much more limited version of concurrency.
  • Complex Interactions and Communication — again, conceptual models provide more general forms of communication than are directly supported in typical OO languages.
  • Declarative Information — constraints and derivation descriptions are common to conceptual models, but OO languages generally rely on applicative expressions.

Woodfield suggests numerous techniques for addressing these impedance mismatches, including the use of design patterns, generic packages, and pattern languages and tools. Ultimately, the best approach would be to evolve our implementation languages so that they support all the concepts found in our models directly, but before we can do this efficiently, we need to gain more experience with how these ideas can be effectively implemented in practice.



Behavioral Design through Seamless Modeling

Steve Liddle presented a position paper describing a seamless approach to behavioral design [9]. According to this approach, the conceptual model and the implementation language used to propose, design, and implement a system should be fully equivalent. Furthermore, the development environment for information systems projects should include several layers that are thoroughly integrated:

  • Metamodel — metaschema that describes features of the model
  • Model instance — "schema" layer that contains structural and behavioral descriptions of a particular system
  • Data instance — actual objects and relationships that are interacting to carry out the behavior of a system and that reflect the current system state

Liddle suggested that underlying such a layered system should be standard mathematical model theory. Given such a well-understood basis, behavioral design transformations can be expressed formally, and thus studied and compared precisely in a model-theoretic framework.

Furthermore, Liddle took the position that the conceptual model should be close to the "real world" as opposed to being close to the "software development world". He views most popular conceptual models as being oriented too much towards developers and not enough towards end users. Pushing a model towards the real world means leaving techniques that are easy to implement efficiently on actual computers with modern programming languages and databases. Overcoming inefficiencies is the biggest challenge of implementing systems in the seamless modeling paradigm.

Liddle also proposed a number of characteristics that he believes should be desirable for conceptual behavior models, such as supporting a mixture of active and passive objects with intra-object concurrency and non-uniform service availability. He then described desirable behavioral design properties, such as maximizing reuse and robustness with respect to possible failure modes. We refer the interested reader to his paper for the complete lists. Liddle concluded with proposals for design transformation patterns and canonical forms of behavior.



Research Directions

At the conclusion of the workshop, we attempted to identify proposed design transformations that could be further studied. However, we agreed that before we can do a thorough job of such identification, we first need better definition of the term "design transformation." Nevertheless, here is the (certainly incomplete) list of transformations we generated.

  • Reduce concurrency
  • Increase concurrency
  • Add transaction specifications
  • Reduce interaction/communication
  • Transform non-uniform service availability to uniform service availability (see [12] for definitions of "service availability").
  • Reduce recursion
  • Integrate views (in the sense of Heinz Frank)
  • Introduce temporal specification
  • Remove temporality
  • Map event-based model to implementation

These and other transformations could be studied profitably as we seek to improve our understanding of behavioral model design.

We also discussed open research issues, and the following directions of investigation with respect to behavioral modeling were suggested:

  • We need better tool support at various conceptual levels (e.g., understanding, design, and implementation).
  • We should use CASE tools to evaluate different metamodels/models.
  • We need to find an integrated way to move from high-level design or specification to implementation
  • We're missing mappings.
  • Look at specific domains — try our theoretical ideas in practice.
  • Work on different categories of transformations: specification to design, design to implementation, etc.
  • Increase our capability to generate code.
  • We need improved metrics for better formal comparison.
  • What is the impact of the use of ERP's like SAP, Bonn, PeopleSoft, Oracle, etc.?
  • Behavioral modeling is not adequately understood — continue dialog on this before we work on transformations.
  • As much as possible, transformations should be two-way, because one-way transformations lose the tie between implementation and conceptual model.


Acknowledgements

We thank all the participants from around the world who attended and contributed to this international workshop. The following is the list of those who attended, with speaker names underlined:

  • Lars Bækgaard, Aarhus School of Business, Denmark
  • Alcides Calsavara, Pontificia Universidade Catolica Do Parana, Brazil
  • Stephen Clyde, Utah State University, USA
  • Cesar Ferreira de Matos, IRS/Finance Ministry, Brazil
  • Heinz Frank, Universität Klagenfurt, Austria
  • Martin Gogolla, University of Bremen, Germany
  • John Hoxmeier, Colorado State University, USA
  • Nick Knowles, OTI, UK
  • Steve Liddle, Brigham Young University, USA
  • Björn Lundell, University of Skövde, Sweden
  • Chiyaba Njovu, University of Wales, UK
  • Katia Regina de Souza, IRS/Finance Ministry, Brazil
  • Carlos Silberman, SERPRO, Brazil
  • Munindar Singh, North Carolina State University, USA
  • Markus Stumptner, Technische Universität Wien, Austria
  • Bernhard Thalheim, Brandenburg Technical University of Cottbus, Germany
  • Harmen van den Berg, Telematics Research Centre, the Netherlands
  • Scott Woodfield, Brigham Young University, USA


References

  1. L. Bækgaard, Conceptual Modeling of Events as Information Objects and Change Agents, in ER'97 Workshop 4 Proceedings, 1997.
  2. W. Clauss, J. Lewerenz, and B. Thalheim, Dynamic Dialog Management, in ER'97 Workshop 4 Proceedings, 1997.
  3. S.W. Clyde, Design Issues in Modeling Object Behavior for Distributed Systems (Position Statement), in ER'97 Workshop 4 Proceedings, 1997.
  4. H. Frank and J. Eder, Integration of Behavior Models, in ER'97 Workshop 4 Proceedings, 1997.
  5. M. Gogolla, On Behavioral Model Quality and Transformation (Position Statement), in ER'97 Workshop 4 Proceedings, 1997.
  6. J.A. Hoxmeier, A Framework for Assessing Database Quality, in ER'97 Workshop 4 Proceedings, 1997.
  7. I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, Reading, Massachusetts, 1992.
  8. Y. Lei and M.P. Singh, A Comparison of Workflow Metamodels, in ER'97 Workshop 4 Proceedings, 1997.
  9. S.W. Liddle, Behavioral Design through Seamless Modeling (Position Statement), in ER'97 Workshop 4 Proceedings, 1997.
  10. S.W. Liddle (ed.), Proceedings of the ER'97 Workshop on Behavioral Models and Design Transformations: Issues and Opportunities in Conceptual Modeling, 6-7 November 1997, UCLA, Los Angeles, California. Available electronically at URL http://osm7.cs.byu.edu/ER97/workshop4.
  11. B. Lundell and B. Lings, Expressiveness within Enhanced Models: An Infological Perspective (Position Statement), in ER'97 Workshop 4 Proceedings, 1997.
  12. O. Nierstrasz, Regular Types for Active Objects, in OOPSLA '93 Conference Proceedings, pp. 1-15, Washington, D.C., October 1993.
  13. C. Njovu and T.W. Lawson, Modeling Temporal Behavior at the Conceptual Level, in ER'97 Workshop 4 Proceedings, 1997.
  14. W.B. Teeuw and H. van den Berg, On the Quality of Conceptual Models, in ER'97 Workshop 4 Proceedings, 1997.
  15. S.N. Woodfield, The Impedance Mismatch Between Conceptual Models and Implementation Environments, in ER'97 Workshop 4 Proceedings, 1997.