With the emergence of object-oriented technology and user-centered software engineering paradigms, the requirements analysis phase has changed in two important ways: it has become an iterative activity, and it has become more closely linked to the design phase of software engineering (Davis, 1993). A requirements analyst builds a formal object-oriented (OO) domain model. A user (domain expert) validates the domain model. The domain model undergoes subsequent evolution (modification or adjustment) by a (perhaps different) analyst. Finally, the domain model is passed to the designer (system analyst), who refines the model into a OO design model used as the basis for implementation. Thus, we can see that the OO models form the basis of many important flows of information in OO software engineering methodologies. How can this information best be communicated? It is widely believed that graphical representations are easy to learn and use, both for modeling and for communication among the engineers and domain experts who tqgether develop the OO domain model. This belief is reflected by the large number of graphical OO modeling tools currently in research labs and on the market. However, this belief is not accurate, as some recent empirical studies show. For example, Kim (1990) simulated a modeling task with experienced analysts and a validation task with sophisticated users not familiar with the particular graphical language. Both user groups showed semantic error rates between 25% and 70% for the separately scored areas of entities, attributes, and relations. Relations were particularly troublesome to both analysts and users. Petre (1995) compares diagrams with textual representations of nested conditional structures (which can be compared to OO modeling in the complexity of the "paths" through the system). She finds that "the intrinsic difficulty of