WPCL$ 2lBVYcZ#|xolbook&-yC8DS0y P['CXP"m^8;Noo)CCdy8C88oooooooooo88yyyYQo~čzCyCyd)ooYsdCkz?;w?zdsoY]Nzkkk`CyCyC8CC!CCCCCCCCCCs?oooooȟYddddQ?Q?Q?Q?zddddzzzzkosddkdsoooYYYYsddddkkkkkkzzQ?Q?Q?Q?ow?????zzzzddȧYYY~]~]~]~]NNNzzzzzzĜkz`z`z`s?zY~]NkksdzNy8yd;YUUoooCd<d<$YYdCCddooCY%7777777777>>>1eOIIOC=OO%+OCbOO=OI=COOhOOC%%47%17171%777V7777%+77O77155<%%%n%%%%%%%%%%7O1O1O1O1O1bII1C1C1C1C1%%%%O7O7O7O7O7O7O7O7O7O7O1O7O7O7O7O7=7O1O1O1I1I1I1I1O7C1C1C1C1O7O7O7O7O7O7O7O7%%%%+O7CCCCCO7O7O7O7O7O7bOI%I%I%=+=+=+=+CCCO7O7O7O7O7O7hOO7C1C1C1O7CO7I%=+CO7O7O7O7O7N'27%177777"SS7!TT7S!117n%%77l==n%1n!>><$$<<mmBBs,>[N6-KWmmmBBsTNNNN0[TTTBBH6<_<d<d<+oodCCddddCo<чnn8!BBnnnyyP7c1RyyXyycnnnѐ~nyRzczXzcyhCBnndhcnnonvyXzXshn~XyBBnss~|y~~~~~~~~~~~~~~~~~~~XXXXXXXyyyyyyyyyyyyyyyyyyyyBBBBBBBBBBBBnnnnnnnsssssssssssszCCn X  88 І#o\  PCcXP#ъ I. A. 1. a.(1)(a) i) a) 1 .1 .1 .1 .1 .1 .1 .1 r  Integrating ObjectOriented Methods and Models ă $Susan Bodily !Scott N. Woodfield Brigham Young University Computer Science Department &TMCB 3361 !Provo, Utah 84602 "EMail Addresses: sbodily@osm7.cs.byu.edu !woodfiel@cs.byu.edu Phone: (801) 3782915 * FAX: (801) 3787775  XK & ABSTRACT ă Most of the literature does not address the important distinction between software development methods and modelling paradigms. Lack of attention to this distinction has led to overemphasis on one or the other (usually the method) to the detriment of the software development process. We describe the advantages of using a method or a model. The characteristic problems resulting from emphasizing one or the other of these aspects of software development are described. These problems can be overcome by recognizing the distinction between methods and models and marrying a formallydefined modelling paradigm with a complementary software development method. Key words:` ` formallydefined modelling, method, software engineering, objectoriented development(#` 7 + + +88  X #o\  PCcXP# 1 .1 .1 .1 .1 .1 .1 .1 1 .1 .1 .1 .1 .1 .1 .1 r  Integrating ObjectOriented Methods and Models ă  X  1XIntroduction (# Practical software development today is accomplished primarily using software development methods. By a software development method we mean the stepbystep technique for developing system models [Boo91]. Though a method is always based on some underlying  X software model [Jac92] ( SN #f\  PC[&P#эJacobson speaks of a method based on an architecture. We call this concept a modelling paradigm., the model is often not formally defined. Thus, both method developers and method users seem to understand the underlying model only at an intuitive level. In contrast, formallydefined software modelling paradigms usually do not have an associated software development method. Without a method there are as many different means to the same end as there are users. It is therefore difficult for one developer to explain to another developer how they arrived at a particular solution. Traceability is compromised. It is difficult to produce a repeatable software development process. The use of either a software development method not based on a formally defined modelling paradigm or a formally defined software modelling paradigm without a well thoughtout method can cause severe problems during software development. This paper addresses these problems and discusses a solution. The distinction between these concepts is applicable to any software development paradigm. However, the research efforts out of which this paper has grown are directed to the objectoriented paradigm. Thus, the discussion in this paper will be in the context of objectoriented development. We will illustrate the concepts using a formallydefined modelling paradigm and three software development methods.#'j + + +88ԌObjectOriented Systems Analysis (OSA) is a formallydefined modelling paradigm developed at Brigham Young University [EKW92] [Cly93]. The formal definition of OSA is a mathematical formulation based on set theory and firstorder logic. It contains three basic models that provide the ability to model declarative information, object behavior, and communication among objects. Research is ongoing to develop model transformations and quality factors that lead from analysis to design then to code giving a working system. There is no software development method currently associated with OSA. We have investigated three software development methods. These methods are discussed  X in Object Behavior Analysis (OBA) [RuG92], Designing ObjectOriented Software [WWW90],  Xf and ObjectOriented Software Engineering A Use Case Approach (OOSE) [Jac92]. These three techniques seem to represent the objectoriented software development methods that are popular today.  X  2XSoftware Modelling Paradigms (# A formally defined modelling paradigm is a mathematical formulation of the software development model along with consistent definitions. The paradigm may also include some notational standards. However, the notation is only a convenience for shorthand communication and can be redefined as desired with no effect on the modelling paradigm. An effective modelling paradigm will cover all modelling possibilities that a software developer may need, to capture the information required for potential applications. Communication is often a serious problem during a software development effort. Communication with the customer as well as within the development team is an important issue. A formally defined software modelling paradigm provides the ability to communicate with anyone unambiguously. The mathematical formulation and precise definitions allow everyone to use the identical conceptual model to consistently interpret all recorded information. There) + + +88 is no room for individual interpretation since the meaning of things is well defined. In OSA, for instance, a relationship between object instances is defined to correspond exactly with the mathematical definition of a relation. No argument is necessary because a relationship in OSA means no more and no less than a mathematical relation. A particularly important aspect of communication during software development is communication with the customer. Customer communication improves with the use of a formallydefined modelling paradigm. Customers most often produce requirements using a natural language such as English. Natural languages are not precise and, in many cases, allow for a wide degree of interpretation. If a developer does not happen to interpret a requirement in the same way as the customer, then the software system will not perform as the customer desires. A formallydefined modelling paradigm can help eliminate this problem. Customer requirements can be stated in precise terms. The customer can then review that interpretation to verify its accuracy. As an example (due to [SES90]), suppose that the sentence "Some people dislike taxes" requires interpretation. There is an ambiguity in the phrase "dislike taxes". Since there is no modifier of the word "taxes", the sentence is likely to have the following symbolic interpretation in firstorder logic_: !#xX!dddddddxREXISTS x` [x~ is~ a~ person~ AND~ FORALL y` (y~ is~ a~ tax~ 8~ x~ dislikes~ y)]x6X@KX@x6X@KX@x6X@KX@8yr8z888x8x`8is8ax8person8y 8y 8is 8a 8tax8xY8dislikesq8y8[x 8(8)a8]8ߑ$(#(# (#(#!!'#$_On the other hand, the sentence may refer to the dislike of certain taxes. In that case the symbolic meaning is_: A#x'dddddddxQEXISTS x` [x~ is~ a~ person~ AND~ EXISTS y` (y~ is~ a~ tax~ AND~ x~ dislikes~ y)]x6X@KX@x6X@KX@x6X@KX@8yr8y8x8x`8is8ax8person8y 8y 8is 8a 8taxj8x:8dislikesR8y8[x 8(8)B8]88ߐ$(#(##(#(#!A'#$_The translation to symbolic logic allows the developer to ascertain precisely what the customer meant.@ ( + + +88!X!'#Q#!''#)A@ԌConsistent model development can be accomplished with a formally defined modelling paradigm. The formal definition enables the development of criteria for model validity and the creation of an automated validity checker. Model validity checking then becomes a matter of automatically checking against known criteria rather than a discussion of personal preferences. The formal definition of OSA, for instance, provides a precise definition of model validity. Automatic checking of model validity is part of all OSA tools. A valid model is not necessarily the model of highest quality. With a formally defined model however, it is much easier to provide a well understood and consistent means for assessing quality. Quality assessment is then moved from the domain of personal preferences into the  Xb domain of measurable criteria. One example of a quality factor in OSA is objectclass  X8 congruency [Cly93]. Objectclass congruency deals with the quality of classification abstractions in system models. Many software development methods require the transformation of an analysis model into a design model and from a design model into an implementation model. For instance, in the  X Structured development method we move from structured analysis to structured design to implementation. Because the underlying models of structured analysis and structured design are not formally defined and the two models appear to be different the transformations in particular  X and the development process in general are characterized as magic. A formally defined modelling paradigm can define well founded and well defined transformations that remove the  X" magic. Such formally defined transformations also help eliminate errors in the transitions. Transformation validity is defined by the modelling paradigm and can be easily checked. One such transformation from a final set of OSA models (a system design) to a programming language has been defined for OSA [Bod93]. ( + + +88Ԍ X  3XSoftware Development Methods (# A software development method is a stepbystep technique for developing a model of a system that is to be implemented. All methods have a modelling paradigm whether or not it is expressly defined in the method definition. A method solicits information about an application and records that information using the method's modelling paradigm. The modelling paradigm profoundly influences the method's definition and application. This influence can be for good or bad depending on the particular modelling paradigm being used. The software development method gives instructions that allow a developer or team of developers to proceed from a requirements specification to a software system. Various models of the system and its components are used during this development activity. The models provide representations of the customer requirements, the software system structure, system communication, the software system implementation, etc. Each of the three methods that we studied provides some kind of representation of the concepts addressed by the method. The representations are related to the requirements of each method. A software development method allows for the management of the software development activity. Since there are both a set of steps and an order of the steps, a management plan can be developed and executed. By this we do not mean to imply that the steps are necessarily sequential or exclusive. Instead, we mean that both they and their order are well defined and so can be used to develop a plan. The plan can then be used according to management techniques to control and direct the development activities. The fact that a management plan exists allows the development of a repeatable process. The process allows measurement of various phases of the software development activity. This measurement can then be used to improve the process for the next software development effort [Hum89]. These management advantages are facilitated by a method but are not usually a part) + + +88 of a method. Jacobson discusses the difference between the method and the management process [Jac92]. OOSE is meant to be used in the context of an appropriate management process. A software development method provides the ability to consistently apply criteria for determining the quality of the software models. The method relies on its underlying modelling paradigm to determine the quality criteria, but the application of those criteria is provided by the method. The consistent application of quality criteria provides further means of managing the software process. For example, in responsibilitydriven design [WWW90], guidelines for assigning responsibilities to classes can be viewed as application of a quality criterion. Most modern software is developed by a team of people working together to produce a single system. A welldefined method provides a framework for team development activities. The method provides the ability for everyone on the team to work using the same set of rules for development. People will be able to determine what their job is and how to perform it since everyone understands the same method and the same associated modelling paradigm. OBA [RuG92], for example, is assumed to be executed using a project process that includes periodic reviews. Thus, those who participate in an OBA development effort know that periodic reviews will be conducted.  X   4XMethod and Model Problems (# As we have seen, both a formally defined modelling paradigm and a software development method have some significant advantages. However, one of them without the other presents significant disadvantages.  Xh$  4.1XFormallyDefined Modelling Paradigm Without a Method (# Using a formallydefined modelling paradigm without an associated method leads to several problems for software development efforts. In general, a formallydefined modelling ( + + +88 paradigm allows users to effectively answer "What?" questions about the system models to be created. However, the answers to "How?" questions are not addressed. Developers attempting to create models understand what the models are and the associated definitions, but they do not know how to produce the models. For example, in an objectoriented modelling paradigm such as OSA, the system models have classes of object instances as basic building blocks. An important activity is finding object instances and/or classes. OSA tells a person precisely what an object instance and an object class are but gives little idea about how to find them. Developers understand quality criteria and model transformations in terms of the modelling paradigm. However, developers can not determine when and how to appropriately apply quality criteria and perform model transformations. For example, the OSA [EKW92] modelling paradigm allows redundancies in the model. OSA developers can determine the quality of a model using redundancy as a quality criterion. In fact, a redundancy removal technique has been developed [EmL89] [Lig94]. However, the information about when and how to apply this technique is not a part of the modelling paradigm. Management of a software development effort that uses no method is difficult at best. Since there is no explanation of how model development is to proceed, it is hard to determine what is happening or how things fit together. Risk assessment and mitigation are difficult or impossible. Since we do not know when or what should be happening, it is difficult to determine if development is on schedule. An important attribute of a successful software development organization is that it can improve itself by having a repeatable process [Hum89]. In addition, a way to measure that process is important to organization and process improvement. Without a method, a repeatable process and process measurement are nearly impossible. While a formallydefined modelling) + + +88 paradigm provides the ability to measure and improve the models themselves, it provides no help for process measurement. Most software development efforts today are performed by a group of people working as a team. A formallydefined modelling paradigm contains no guidelines for team development. The modelling paradigm should provide a framework for team development by allowing multiple views of the system, model integration, and various levels of abstraction. But, the modelling paradigm does not provide the team management techniques required to apply the framework. If several people develop different parts of the system model using OSA [EKW92], for example, there will likely be object classes that are the same but exist in two different models with two different names. The OSA modelling paradigm allows for this possibility. However, the resolution of the naming problems is not described. A formallydefined modelling paradigm may be difficult to use for the average practitioner. Formallydefined paradigms are very detailed mathematical structures that use very sophisticated ideas and techniques. The mathematical sophistication to properly understand and use the modelling paradigm are often not present in the average software developer. Thus, most teams that need to apply the formallydefined modelling paradigm may experience difficulty.  X   4.2XA Method Without a FormallyDefined Modelling Paradigm (# Applying a software development method without a formallydefined modelling paradigm is common but presents many problems. A method allows developers to answer the "How?" questions about system models. But, the "What?" questions about those same models are not precise or agreed upon. A software development method provides guidelines for producing system models. Without a formallydefined modelling paradigm, these guidelines can not be consistently interpreted by developers. The guidelines are interpreted in light of the underlying modelling)  + + +88 paradigm. Since that paradigm is not formally defined, there is no way to fully understand the guidelines or the models to be produced. OBA [WWW92], for example, adopts objectoriented concepts published by several authors. The referenced authors have no formal definition and, in fact, define things in a fashion that are similar to but not the same as each other. So, the given definitions and descriptions can not be consistently interpreted or applied. Communication is often one of the most serious problems for a software development team. Without a formallydefined modelling paradigm, there is no agreement about the most basic concepts that affect the system model being developed. The meaning of the models produced is not uniformly understood. Consequently, the information that the model is intended to communicate is often misinterpreted. OOSE [Jac92], for instance, provides definitions for many of the modelling concepts it uses. However, not all of the definitions that are needed are  X provided. The definition of object refers to a state. However, a developer does not learn  X precisely what a state is. The development team is left to infer the meaning of state. Determining the precise meaning of a customer requirement may be difficult without a formally defined modelling paradigm. The use of natural language leads to an imprecise statement of requirements. Without a formallydefined modelling paradigm, it is difficult to make ambiguous requirements precise. When a developer does not interpret the requirements in the same manner as the customer, the software system produced will not satisfy the customer's requirements. It will instead satisfy the developer's requirements. Software development productivity is adversely affected by the inability to communicate effectively. When commonly used expressions do not mean the same thing to everyone on the team, much time is wasted. In the best case, time is wasted while people attempt to explain their personal interpretation. In the worst case, time and good will are squandered while people argue about meanings.)  + + +88ԌAlthough the planning and tracking aspects of management of a software development effort are facilitated by a method, the technical problems caused by the lack of a formallydefined modelling paradigm make other aspects of management very difficult. For example, inherent inconsistencies of interpretation can cause models developed by different people on the team to be difficult to consolidate. These differences in interpretation must be resolved and the work redone. This wastes time and money. Without a formallydefined modelling paradigm, the quality of models produced is not uniform. The quality of the developed software may be assessed differently by the software quality assurance organization and the development organization. This may have grave consequences for the entire development effort. For instance, OOSE [Jac92] places emphasis on localizing potential system changes as a quality indicator for design. While intuitively we may agree that this is a worthy quality goal, there is little discussion of the precise meaning of  X localization of change. It is impossible to decide how to evaluate it in any particular case. In methodoriented techniques, the rules for moving through software development phases may be difficult to interpret. There are often illdefined criteria for moving from one phase to  XR the next. A consistent interpretation and a good foundation is required to remove the magic from the rules for moving through stages. For example, the responsibilitydriven approach [WWW92], describes choosing classes and attributes from the requirements specification. There is no satisfactory definition of the difference between a class and an attribute. It appears that there are some arbitrary decisions made in transitioning from the requirements specification to a class or attribute. So, there is not a clean transition from the requirements specification to the analysis model.B&  + + +88Ԍ X  5XCombining a FormallyDefined Modelling Paradigm With a Method (# The reader may have noticed that most of the strengths and weaknesses that we have discussed for a formallydefined modelling paradigm alone and a software development method without a formallydefined modelling paradigm are complementary. So, if we combine a formallydefined modelling paradigm with an appropriate software development method we should be able to solve most of the problems that we have discussed. And, indeed, this is true. The strengths and weaknesses offset each other so that most problems are solved. It is important to note that the chosen method must be appropriate for the formallydefined modelling paradigm. The modelling paradigm is the foundation that the method is built on. Thus, the modelling paradigm has a profound effect on the method. In order to reap the considerable benefits of the formallydefined modelling paradigm, the method and the modelling paradigm must be complementary. The one problem of formallydefined modelling paradigms that is not clearly addressed by the marriage of a modelling paradigm with a method is the easeofuse problem. This problem is addressed by using a modelling paradigm that is built around the idea of tunable  XN formalism. "A software model with tunable formalism must (a) be sufficiently expressive for practitioners, (b) have a formally defined syntax and semantics, and (c) allow various levels of detail and completion." [Cly92] The combination of a formallydefined modelling paradigm, tunable formalism, and a complementary method provides a solid foundation for software development. Problems associated with a formallydefined modelling paradigm alone or a software development method alone are solved with this combination. Such a combination would provide a very good foundation for a solid software engineering discipline.(  + + +88Ԍ X  5.1XOSA as a Modelling Paradigm for Existing Methods (# Of the three methods we have discussed, none has a formallydefined modelling paradigm by our definition. The modelling paradigms used by the three approaches are similar but are not exactly the same. However, without a formal definition, it is difficult to tell whether they are equivalent. This is an illustration of one of the problems with methods that do not have a formallydefined modelling paradigm. The three techniques appear to exhibit the problems outlined in the previous discussion. To obtain an improved software development method, we have looked at using OSA as the modelling paradigm for one of the three methods that we have investigated. We have found that none of the three methods is suitable without modification since their inherent modelling paradigms differ from the OSA paradigm in significant ways. For example, each method assumes a modelling paradigm in which the behavior of any object instance is only activated by specific calls to procedures (or methods) that implement the behavior. This implies a sequential model of system operation. The OSA paradigm treats each object instance as an entity that operates independent of every other object instance in the system except as specifically synchronized by communications (interactions) between object instances. This implies a concurrent model of system operation. A particular example of the problem that this causes can be seen when attempting to design a system that includes an independent clock as a part of its operation. The clock is an object instance that performs some timing function and then informs other object instances when a particular timing sequence is complete. It receives no input from any other object instance. Object classes with instances that exhibit this kind of behavior (no requested operations) are specifically excluded when using OBA [RuG92]. These kinds of object classes are not handled well by any of the three methods. On the other hand, this kind of object class is a natural part of an OSA model [EKW92] [Bod93].)  + + +88ԌThus, these two views of system operation are quite different and require different approaches to system analysis and design. This makes any one of these methods (and likely other popular methods) unsuitable as a complementary method for use with OSA.  Xv  5.2XA Method for OSA (# OSA currently has no complementary development method. Consequently, the development efforts associated with OSA research have encountered many of the problems of a formallydefined modelling paradigm with no method. The only exception appears to be that OSA is not difficult to use since it incorporates tunable formalism. To improve OSA we need a complementary development method. Since we suspect that none of the popular methods will provide an adequate method for OSA, we need to create a new method for OSA. The methods that we have studied have several good features that are suitable techniques to consider as a part of the OSA method. We will discuss a very high level outline of a method for use with OSA using ideas and techniques described by the three researched methods. Although this proposed method is stated as a set of steps, it is not intended to be accomplished in a completely sequential fashion. Everyone seems to agree that an iterative method is the most appropriate for objectoriented development [Jac92] [RuG92] [WWW90]. A method should start with a step that establishes the context of the development [RuG92]. During this step we identify the project goals and objectives and generate management information such as development plans. This step provides both business and technical goals. It sets the management foundation for the development effort. The development starts with the requirements specification. The requirements specification should describe what the software can do and what it can not do [WWW90]. It should also provide operational constraints and the relative importance of various requirements. The ( + + +88 requirements specification is generally provided by the customer, but may be created or augmented by the developer in conjunction with the customer. Once the requirements specification is agreed upon, scenarios for system operation are developed. The scenarios should cover system operation to the largest extent possible without  XH regard to any particular operating environment [Jac92]H( S #f\  PC[&P#эThe Use Case is used by Jacobson. These correspond to the scenarios that we talk about.. From these scenarios the system object classes, relationships, and appropriate constraints can be extracted giving us the beginning of the analysis model. The Object Relationship Model (ORM) is then created using this information. The ORM represents the declarative information of the system. We now perform a transformation on the initial system model that determines the appropriate levels of abstraction. Highlevel object classes are created as required to produce an ORM with the required abstractions. From this point on when we refer to object classes we will mean these highlevel object classes. The scenarios identify various responsibilities for each object class [WWW90]. The behavior of each object class carries out these responsibilities. The object class behavior is described by the Object Behavior Model (OBM). The behavior of each object class is a result of its use in the various system scenarios. During the execution of the system scenarios, object classes communicate with each other. This communication accomplishes tasks such as requesting some action, requesting information, sending information, etc. We may think of object classes as having contracts with each other for services [WWW90]. The contracts are satisfied using interactions. These communication activities are described through interactions between object classes and recorded using the Object Interaction Model (OIM).:&j + + +88ԌOnce the three submodels of the system are created, the scenarios are used to verify that the system model accurately represents the system as defined by the requirements specification. The verification is done by performing system runthroughs using the scenarios. This verification can be done by hand or with the help of a prototype. A rapid prototyping technique is available for a system model done using OSA [Com94]. During the verification of the system model, we apply modelling paradigm quality criteria. The models are then changed as necessary to give a system model of the highest possible quality. We can now begin design. System design includes two activities. First, we continue building the system model by adding information required for system operation in a particular operating environment. Second, we apply additional model transformations to give the type of model and the level of abstraction that we require for implementation. Consequently, the design model of the system is a refinement of the analysis model. Delaying the application of information dealing with a particular operating environment to the design phase gives us the advantage that we have created an analysis model that can be reused in any desired operating environment [Jac92]. The development activity can begin at the design phase for new developments and not at the analysis phase. Strategies similar to those used for development of the analysis model are used for development of the operatingenvironmentspecific portions of the design model. Once the design model has been completed, the implementation can begin. Semiautomatic transformation of the system model to code is highly desirable. Such a transformation gives a more accurate implementation of the model and allows maintenance to take place with the system model rather than with the code. The system model is likely to be ( + + +88 easier for most people to understand and maintain. As has been previously mentioned, such a translation is available for OSA. Traceability is a very important element to consider for any software development activity [RuG92]. Traceability allows developers to determine "Why?" something is a part of the system model. Our proposed method for OSA preserves traceability. We provide traceability in two ways. First we base model development on scenarios that can be directly traced to the requirements specification. Second, we only allow formallydefined model transformations. So, we can always tell how any particular phase of the system model was derived. We can tell "Why" something is in the system model. We have not said much about the management of the software development process in this discussion. We have prepared for good management activity by providing a step that establishes the management framework. We assume that the proposed method will be performed within the framework of a good software development process [Jac92]. One purpose of the proposed method is to facilitate the management activity, but not to describe it. This proposed method has used ideas from each of the three software development methods that we studied in preparation for this work. Each has strengths and overlapping ideas. Credit is due to each of them for ideas used in this proposed method. Details of application of the proposed method are a subject for further research.  X  6XConclusion (# In order to provide the best foundation for good software engineering activities, we require both a formallydefined modelling paradigm and a complementary software development method. OSA provides a good formallydefined modelling paradigm for objectoriented software. Unfortunately, it has no associated software development method. Three candidate methods have been studied with no success at finding a complementary method for OSA. We have used good) + + +88 ideas from each of the three candidate methods to propose a software development method for OSA. Further research into the application of the proposed method is needed. Current research in this area is ongoing. + + +88  X $ Bibliography ă  X [Bod93]` ` Bodily, S., A Direct Ada Implementation for ObjectOriented Systems Analysis, Masters Thesis, Brigham Young University, 1993(#`  XL [Boo91]` ` Booch, G., Object Oriented Design with Applications, Benjamin/Cummings Publishing Co., 1991(#` [Cly92]` ` Clyde, S.W., D.W. Embley, S.N. Woodfield, "Tunable Formalism in Objectoriented Systems Analysis: Meeting the Needs of Both Theoreticians and  X Practitioners", OOPSLA'92 Conference Proceedings, Vancouver, British Columbia, Canada, 18-22 October, 1992, pp. 452465(#`  X@ [Cly93]` ` Clyde, S.W., An Initial Theoretical Foundation for ObjectOriented Systems  X Analysis and Design, PhD Dissertation, Brigham Young University, 1993(#`  X [Com94]` ` Compton, J.W., Executable OSA, Masters Thesis, Brigham Young University, 1994(#`  X [EKW92]` ` Embley, D.W., B.D. Kurtz, and S.N. Woodfield, ObjectOriented Systems  Xj Analysis: A Model Driven Approach, Prentice Hall, 1992(#` [EmL89]` ` Embley, D.W., T.W. Ling, "Synergistic Database Design with an Extended Entity X Relationship Model", Proceedings of the 8th International Conference on Entity X Relationship Approach, Toronto, Canada, 1820 October 1989, pp. 118135(#`  X" [Hum89]` ` Humphrey, W.S., Managing the Software Process, AddisonWesley Publishing Company, 1989(#`  Xf& [Jac92]` ` Jacobson, I., et al., ObjectOriented Software Engineering A Use Case Approach, AddisonWesley Publishing Company, 1992(#` <( + + +88Ԍ X [Lig94]` ` Light, J., A Relational Database Design Tool for ObjectRelationship Models, Masters Thesis, Brigham Young University, 1994 (in preparation)(#`  X [RuG92]` ` Rubin, K.S., A. Goldberg, "Object Behavior Analysis", Communications of the  X~ ACM, Vol. 35, No. 9, January 1992, pp. 4862(#`  XT [SES90]` ` Smith, D., M. Eggen, R. St. Andre, A Transition to Advanced Mathematics, Brooks/Cole Publishing Company, 1990(#`  X [WWW90]` ` WirfsBrock, R., B. Wilkerson, L. Wiener, Designing ObjectOriented Software, Prentice Hall, 1990