Behavioral Design through Seamless Modeling

¾ Position Statement ¾

Stephen W. Liddle
School of Accountancy and Information Systems
Marriott School of Management
Brigham Young University
Provo, UT 84602-3068
e-mail: liddle@byu.edu

1 A Seamless Model and Model-Equivalent Language

A seamless model [LEW94] with an executable conceptual model allows us to define a model-equivalent language [LEW95], which overcomes many of the impedance mismatches described in [Woo97].

Defⁿ

We say that a software engineering model M and a programming language L are equivalent if

for each model instance i of M there exists a program p of L such that the semantics of i and p are one-to-one, and
for each program p of L there exists a model instance i of M such that the semantics of p and i are one-to-one.

By "semantics are one-to-one", we mean that for each construct in the program, there is a corresponding construct in the model instance and vice versa. Given such equivalence, we say that L is model-equivalent with respect to M and M is language-equivalent with respect to L.

Model instances created using a language-equivalent model are already directly executable, even though the performance of such a system may be slow, and indeed perhaps unacceptable for production purposes. However, a model-equivalent provides a direct path to an executing system without encountering the kinds of "impedance mismatches" described elsewhere [LEW94, LEW95, Woo97]. Because the conceptual connection between analysis, design, and implementation model instances is clear, programs implemented in a model-equivalent paradigm can be more easily understood by a wider variety of stakeholders. Moreover, we can deal with efficiency concerns the same way the database community has dealt with logical versus physical design. The idea of a model-equivalent language is directly analogous with the idea of a conceptual model and a database schema.

We have developed the Object-oriented Systems Model, or OSM, and its model-equivalent language, Harmony, to study the ideas of model/language equivalence. OSM/Harmony is formally defined using a seamless model architecture. This architecture is seamless in terms of the model/language equivalence described earlier, and it is also seamlessly integrated across the following layers:

Layer	Example
Metamodel	Object Set, Relationship Set, Constraint
Model instance	Person, Name, Person has Name
Data instance	áp₁ñ, á"Sally"ñ, áp₁, "Sally"ñ

A model instance (or application model) in OSM is an instance of the OSM metamodel in the same way that a data instance is an instance of an application model. Our metamodel is expressed in OSM itself, and it is formally defined using ideas of standard mathematical model theory. Because of the seamless integration across architectural layers, an object can reflect on the structure of its data instance, and can issue meta-level queries over the application model.

Increasingly, researchers are using the metamodel/model instance/data instance metaphor. Indeed, with the recent request for proposal from the Object Management Group (OMG) for an object-oriented analysis and design model standard, it is becoming more common to see a four-tier architecture with meta-metamodel at the top layer of this architecture [UML97]. This may not be strictly necessary since the metamodel can be expressed recursively in its own language and formally mapped to mathematical model theory as with OSM. (As a possible research project, it may be useful to show how UML can be formalized as an instance of a meta-metamodel based on standard mathematical model theory instead of the current UML meta-metamodel, the OMG Meta Object Facility, or MOF [MOF97]. This is not to say that the MOF is useless, because there are many other justifications for defining the MOF.)

A formal definition grounded in standard mathematical model theory allows us to communicate clearly, understand thoroughly, and make formal characterizations of design transformations. Starting with mathematical model theory lets us leverage a considerable amount of existing work, since we do not need to prove the theory's correctness (as, for example, we must do with the OMG MOF). It is very important that a conceptual behavior model be grounded in a formalism that readily supports formal reasoning. Otherwise we will not be able to make clear and conclusive statements about whether our design transformations are information preserving.

It is our position that the conceptual model should be close to the "real world", instead of being close to the "software development world". OSM takes an ontological approach to object-oriented modeling that uses "natural" concepts such as generalization/specialization and relationships, not programming concepts such as inheritance and instance variables. In the ontological approach, concepts have meanings that correspond to what one might find in a natural-language dictionary, rather than a computer scientist's definition. For example, in OSM, an object is a representation of a person, place, or thing, concrete or abstract. Contrast this point of view with that of most object-oriented programming languages and analysis/design models, where an object is an instance of a class.

As demonstrated by the model-equivalent language effort, being close to the real world does not imply that the transformation to the software development world must be contorted and painful. This is not to say that optimization of such a system is easy. We recognize that optimization is the largest challenge as we move from conceptual model to production-quality implementation.

2 Desirable Characteristics of a Behavior Model

There are many desirable characteristics of a conceptual behavior model. We now mention a few.

It should be computationally complete. This is a minimum standard that is easy to reach with just a few commands (for example, see the S language of [DW83]).
A less straightforward property to satisfy is that a conceptual behavior model should make logical description of algorithms convenient to do. It should provide a wealth of specification paradigms, such as imperative, structured techniques, deductive programming, etc. However, these paradigms should all be built on a compact core of behavioral constructs.
It should support a mixture of active and passive objects. Few systems of any complexity will be composed of entirely active or entirely passive objects. Active objects should be concurrent and should each support multiple threads of control. Real-world active objects (such as people) commonly have many concurrent "threads of control" (such as walking and chewing gum at the same time).
A behavior model must have a single, formal interpretation. We advocate formally interpreting behavioral models using standard mathematical model theory.
It should support models that normal humans understand, such as intra-object concurrency and non-uniform service availability.
It should support all forms of interaction. Here are several kinds:
- asynchronous versus synchronous communication
- point-to-point communication versus broadcast
- discrete and continuous interaction
- simple synchronization of threads
- one-way information flow coincident to thread synchronization
- bidirectional information flow coincident to thread synchronization
It should support analysis, specification, design, implementation, and evolution activities, all in the same conceptual model.
When we have adequate power, "notational" or "view" issues can be dealt with as templates over the core concepts. A simple core is essential. Insofar as possible, the core should be implementation and domain independent. "Macro packages" or "templates" can be much more extensive, and when necessary, domain-specific. We thus advocate a minimalist point-of-view with respect to the core conceptual model.

3 Desirable Properties of a Behavioral Design

Some of the properties our behavioral designs should strive to possess include:

The sine qua non of a behavioral design is that it performs all desired functions properly (in a correct and timely fashion). Notwithstanding the importance of this basic desire, this is a major challenge to accomplish! We assume our designs will have functional problems, and we work defensively to ensure that the impact of unforeseen and undiscovered bugs will be minimal.
Given the practical inevitability of bugs, we desire that our designs be robust with respect to possible failure modes.
A design should be as simple as possible (but no simpler!). This is extremely difficult to quantify, but we can at least begin by mapping the computational complexity of our algorithms. In some cases it may be possible to algorithmically compute a function's complexity. In other cases, this quantification will be manual and possibly subjective.
It should be clean and elegant, relatively easy to understand and maintain. This is a property that is hard to measure, and is currently very subjective. Mature organizations (in the SEI Capability Maturity Model sense) will have long-term data that could lead to ex post facto intuition about which designs hold up well over time. We should continually explore this kind of information to test our designs and improve the state of the practice.
A good behavioral design can be readily (perhaps automatically) implemented.
And it can be implemented so as to execute efficiently.
Usually, it should be as platform independent as possible. All else being equal, certainly it is better to have a design that can be reused in many situations.
A good design will minimize redundancy in new development, and leverage existing design elements through reuse. This property is relatively easy to quantify (e.g., we can compare the ratio of new lines of code to reused lines).
A good design carefully and correctly specifies concurrency constraints. Transaction specification is a convenient way to accomplish this (in OSM, we use a nested transaction model).

4 Canonical Forms and Transformations

Embley suggests several useful design forms for object-oriented behavior specifications [Emb98]:

ADT -- many uniformly available services that can execute sequentially within an object module (in the classical programming case, there is only one thread of control -- there is no concurrency).
Queued Concurrent Requests -- requests come concurrently to a queue manager, from which an object module can process requests serially, perhaps according to priority specifications.
Transaction Processing -- using a transaction processing facility, concurrent requests can be processed. To accomplish this, operations that could conflict are placed within transactions so the transaction manager can control concurrency issues.
Multiprocessing and Distributed Processing -- the idea is to maximize concurrency in a behavioral specification so that the operating system (or distributed computing environment) can more easily spread work among parallel processors.

We do not believe that this list of useful forms is complete. However, these are candidates for canonical forms.

We now note a number of transformation patterns (some of which are illustrated in Chapter 11 of [Emb98]) that could be applied during behavioral design:

Reduce (possibly minimize) concurrency.
Increase (possibly maximize) concurrency.
Add transaction specifications.
Reduce (possibly minimize) active-object interaction or thread-to-thread communication.
Transform non-uniform service availability to uniform service availability.
Reduce (possibly minimize) recursion.

Again, this list is incomplete. Other transformations may relate to generalization/specialization structures, cyclomatic complexity of algorithms, etc.

Most transformations should be information-preserving. (If a transformation is not information preserving, it should be known that it is not.) Proof of information preservation in behavioral specifications is problematic. From Rice's Theorem [DW83], we understand that in general we cannot make algorithmic statements about algorithms. Only in specific, well-behaved cases can we prove, for example, that two programs compute the same function, or that a particular program halts. Thus, we cannot take two distinct behavioral specifications and in general prove that they are equivalent, or even that one implies the other. This is a general issue we need to be aware of. But fortunately, in the case of design transformations, we can show that a particular small change preserves the semantics of a behavioral specification.

5 Conclusion

OSM is built around seamless model that is formally defined in a model-theoretic way. As such, OSM is a good candidate for use in studying behavioral design issues. Its model/language equivalence and simultaneous closeness to the real world are unique and powerful.

Behavioral modeling and design are becoming increasingly useful in the development of advanced applications. There are numerous open research problems in this area, and the ideas listed in this position statement point toward some potentially fruitful areas of research. We hope that the result of this workshop is to more fully discuss and document some of these areas.

References

[DW83] Davis, M.D., and E.J. Weyuker, Computability, Complexity, and Languages, Academic Press, Inc., San Diego, California, 1983.

[Emb98] Embley, D.W., Object Database Development: Concepts and Principles, Addison-Wesley, Reading, Massachusetts, 1998.

[LEW95] Liddle, S.W., D.W. Embley, and S.N. Woodfield, "Unifying Modeling and Programming through an Active, Object-Oriented, Model-Equivalent Programming Language," Proceedings of the Fourteenth International Conference on Object-Oriented & Entity-Relationship Modeling, Lecture Notes in Computer Science, 1021, ed. M.P. Papazoglou, pp. 55-64, Springer Verlag, Gold Coast, Queensland, Australia, December 1995.

[LEW94] Liddle, S.W., D.W. Embley, and S.N. Woodfield, "A Seamless Model for Object-Oriented Systems Development," Proceedings of the International Symposium on Object-Oriented Methodologies and Systems, pp. 123-141, Palermo, Italy, 21-22 September 1994.

[MOF97] Meta-Object Facility (MOF) Specification, Cooperative Research Centre for Distributed Systems Technology (DSTC) et. al., www.dstc.edu.au/Meta-Object-Facility/Publications.html, October 1997.

[UML97] UML Semantics, version 1.1, Rational Software et. al., www.rational.com/uml, September 1997.

[Woo97] Woodfield, S.N., "The Impedance Mismatch between Conceptual Models and Implementation Environments," Proceedings of the ER'97 Workshop on Behavioral Models and Design Transformations: Issues and Opportunities in Conceptual Modeling, osm7.cs.byu.edu/ER97/workshop4/sw.html Los Angeles, California, 6-7 November 1997.