James E. Rumbaugh

Relations as semantic constructs in an object-oriented language

The relation as a semantic construct in an object-oriented language clearly expresses associations and constraints among objects which would otherwise be buried in implementation code. The externalization of references between objects permits a symmetric, non-redundant conceptual model which merits its own special notation and predefined operations. The object-relation model, which combines the object-oriented model with the entity-relationship model from data base theory, is particularly useful for designing and partitioning systems of interrelated objects. Relations can be implemented efficiently using hash tables. The model proposed here has been fully implemented in an object-oriented language written by the author which has been used to implement several production applications.

Relational database design using an object-oriented methodology

Of the many approaches to relational database design, the Object Modeling Technique (OMT) is particularly effective. A comprehensive explanation and two applications show the semantic improvement of OMT over other approaches.

Controlling propagation of operations using attributes on relations

Controlling the propagation of operations through a collection of objects connected by various relationships has been a problem both for the object-oriented and the data base communities. Operations such as copy, destroy, print, and save must propagate to some, but not all, of the objects in a collection. Such operations can be implemented using ad hoc methods on objects, at the cost of extra work and loss of clarity. The use of propagation attributes on the relationships between objects permits a concise, intuitive specification of the manner in which operations should propagate from one object to another. These concepts have been implemented in the object-oriented language DSM and have been used to write applications.

An object-oriented relational database

A relational DBMS and an object-oriented programming language can be combined to yield a surprisingly effective OO-DBMS for many applications.

DSM: an object-relationship modeling language

The Data Structure Manager (DSM) combines object-oriented programming with semantic data modeling concepts in the context of the C language. DSM is a full-featured object-oriented language which includes single and multiple inheritance, class descriptor objects, metaclasses, choice of method binding time, error handling, persistent objects, modularity, and an interactive interpreter in an efficient manner. In addition, DSM supports the association and aggregation relationships as part of the Object Modeling Technique (OMT) used for conceptual design. DSM has been used since 1986 to build a variety of research and production-quality software such as an advanced CAF/CAD system.

Methodology standards: help or hindrance?

Over the last 12 months there has been growing interest in the possible “standardization” and/or “convergence” of object-oriented analysis and design methodologies. The key issues discussed by the panellists focus on whether standardization NOW is to be encouraged or resisted whether standards are a help or a hindrance to the further maturation of 00 methodologies. Each panellist has been closely associated with the development of an 00 lifecycle methodology. Some of the issues raised include:

“methodology standards: help or hindrance?” held at OOPSlA 94 October 1994, Portland, Oregon: Report on panel

The proliferation of methodologies has prompted some to call for standards in this area. The members of this panel, all prominent methodologists, stated their positions on this topic and then answered questions from the floor. Following brief introductions by the chairman (Monarchi), each panelist made a brief position statement. ------------------------------------Grady Booth started by looking backwards at structured analysis and design in order to learn from the past. He noted that even in this older approach to software development, there were identified gaps and incomplete convergence. However, he was more optimistic for object-oriented analysis and design because, he argued, we know at least some of the things that work and some that don’t. Booth noted a subtle shift in the last 12 months in which engineering issues were being addressed to yield a simple solution. This implies a growing maturity in 00 methodologies. He stated emphatically that there should not be a methodology convergence in terms of standards. “Forcing a standard would be contradictory to our aims. We can standardize notation, but process is a little way off.” -----------------se -_--_-------------The second speaker, Brian Henderson-Sellers, started with a brief overview of what a methodology should be: it should cover the whole lifecycle; provide process support; embody a general underlying philosophy regarding the degree of iteration necessary when using OT (as well as guidelines to management); provide specific and detailed management and technical techniques including discussion of roles played within the project team; delineate deliverables (type and timing); support a hierarchy of abstraction levels (e.g. class, subsystem, pattern); embody the notions of contracting; and offer an overlay of complexity management techniques (e.g. layering, sheets, subsystems, selective visibility). A methodology should not be seen as a cookbook but as a guide or roadmap which provides the ground rules rather than the implementation details with all their potential variability. So rather than setting standards, a better approach would be to seek interoperability and to identify a meth(ldologica1 “core”. This core would not necessarily be a common denominator of today’s approaches, but instead would identify for industry and CASE vendors a minimal functionality desirable for all 00 methodologies. This will assist everyone in developing the tools to help OT grow from the current < 5% to > 50% of software development. As an added benefit, such a core would encourage the creation of new ideas in this still rapidly maturing field, rather than stifling new research. An analogy to illustrate this notion of a core involves passenger cars. Rolls-Royce and Volkswagen produce markedly different vehicles serving different markets. Yet if you know how to drive one, you know how to drive the other. There is a shared functionality, a core, yet there is also a great deal of flexibility in the implementation and extension of that core. In a similar manner, different methodologies can be the “same” yet have dramatically different realizations.