Object Oriented Analysis through a Knowledge-Based SystemBoumediene BelkhoucheAlejandro Mendoza Gami~noDepartment of Computer ScienceTulane UniversityNew Orleans, LA 70118phone (504) 865-5840fax (504) 862-8747email bb@cs.tulane.eduAbstractThis research is an attempt to provide some basis for a systematic and problem independent object-oriented analysis approach. It presents an object oriented requirements analysis strategy based on aknowledge representation scheme. An abstract model and a strategy for object-oriented requirementsanalysis (OORA) are described. The proposed OORA strategy is based on a semantic-net represen-tational scheme that provides a set of constructs to organize the requirements model in a structuredform. Moreover, the graphical notation of this knowledge representation formalism enhances the under-standability of the requirements model and facilitates the mapping of the objects speci�ed in the user'srequirements.To demonstrate the viability of this approach a prototype knowledge-based system was implemented.The implemented knowledge-based system is capable of performing di�erent analyses on an initial re-quirements model to identify: (1) common patterns among classes; (2) message-connections; and (3)groups of cohesive classes. The ability of the system to identify such properties can be of great bene�tto the software engineer.Keywords and phrases: object-oriented analysis, semantic nets, knowledge-base system, OORA strategy,graphical notation. 1

1 IntroductionSeveral approaches to object-oriented requirements analysis (OORA) have appeared recently (e.g. [1, 2, 3,4, 5, 6, 7, 8]). Although they provide a rich set of heuristics to extract, organize, and classify the essentialaspects of the users requirements, they have not developed to the point of providing automated techniques forrequirements analysis. One reason for the current low level of automated assistance stems from the di�cultiesof identifying and representing the essential aspects of the user's requirements. The purpose of this researchis to develop a strategy for object-oriented requirements analysis supported by a knowledge-based system toassist the human analyst in the elaboration and re�nement of a requirements model. A crucial element inour approach is the identi�cation of a knowledge representation formalism with the characteristics likely tobe required in the creation and re�nement of an object-oriented requirements model [9].We propose a strategy for OORA based on a knowledge representation scheme. We begin with a discussionof an abstract OORA model describing the underlying concepts on which our approach is based. Later, adescription of the strategy is presented in terms of steps-substeps. We developed a knowledge-based systemsupporting our OORA strategy in order to demonstrate its viability. The composition of this system and thedata structures used as internal representation are also described. To conclude, we illustrate the feasibilityof our approach by applying it to an example by Coad and Yourdon [6].We present an abstract OORA model which is the product of a synthesis of various OORA approachesthat have been broadly taken as reference [6, 10, 5, 11, 12]. Since it seems evident that the multimodelapproach will prevail in future OORA methods, we have adopted this approach in our abstract model.Hence, our description of what we perceive are the core concepts involved in the OORA methodology ispresented taking into consideration the distinction between the components of the structural model and thecomponents of the behavioral model.2 Strategy for Object-oriented Requirements Analysis (OORA)Our approach to OORA consists of developing an OO requirements model in two major steps. The �rststep is concerned with the construction of an initial model using a formalism of representation to organizethe requirements in a structured form. The second step relates to the re�nement of this model through anautomated system. Figure 1 gives an overview of our strategy.Domain knowledge is needed throughout the analysis process to help guide the requirements modelingprocess. In the �rst step, the analyst uses only his or her intuitive understanding of the user's requirements1

user’s requirements

model refinement

initial OORA model

final OORA model

domainknowledgeandheuristics

analyst’s

automatedsystemFigure 1: Overview of the OORA strategytogether with a set o heuristics to extract and formalize an initial OO requirements model, whereas in thesecond step of the strategy, the analyst is assisted by an automated system to complete the model using agroup of generalized procedures that facilitate its re�nement through an analyst-system dialog . Our OORAstrategy is de�ned as follows:1. Extract an initial OORA model(a) identify potential classes(b) identify structures(c) identify collaborations2. Re�ne the initial model(a) discover patterns among classes(b) discover message connections(c) discover groups of cohesive classes2.1 Extracting an initial OORA modelOur strategy starts from the information contained in the informal requirements document by the usersaccording to the problem domain. The analyst, henceforth, performs an initial analysis on this informal2

requirements, and then builds an initial OORA model using a semantic net based representation. Weprovide a set of valid relationships to be used in the development of this initial model. The information tobe represented in the model involves both structural (static) and behavioral (dynamic) characteristics of theproblem domain. The �rst analysis of the user's needs concentrates on identifying candidate classes and theirassociated attributes, structures, and collaborations. To facilitate this analysis, we suggest a combination ofthe heuristics proposed [13, 14, 6].2.1.1 Identifying potential classes.At this stage the analysis should concentrate on discovering candidate classes and de�ne the attributes thatcharacterize each class. The primary motivation for identifying classes and objects is to have the OORAmodel closely match the conceptual model of the application domain.� Classes. In our semantic net based representation, nodes represent classes and objects in the real world.But an object is not restricted to a physical tangible thing. In fact, objects can be identi�ed fromat least three di�erent perspectives. The data perspective suggests that we can identify objects bylooking at the problem domain itself, other systems, physical devices, events remembered, roles played,locations and sites, and organizational units. The functional perspective is based on identifying objectsby discovering what they do, not what they are. From this perspective what we have to do in orderto identify objects is ask ourselves, what does an object has to do to exist? This viewpoint implieslooking for verbs in the requirements document, rather than looking for nouns as is most commonlyrecommended. On the other hand, the behavioral perspective is concerned with discovering objectsby focusing on the collaborations in which objects participate, the primary questions here are: howdo objects communicate? With whom? How fast? How do they respond to signals? This perspectivesuggests identifying objects by analyzing the list of events to which the system is required to respond.� Attributes. Each class is characterized by a number of attributes or data elements relevant to that class.Our semantic net representation provides the has-characteristic relationship to specify the semanticassociation between a class and its attributes. These attributes serve to prescribe the characteristicsof the objects in a class and to realize what is meant by the names of the classes.2.1.2 Identifying structures.In order to de�ne a consistent semantic interpretation of a class corresponding to the problem space, theanalyst should de�ne the structural relations that this class might bear to other classes in the domain.3

Henceforth, after identifying classes, the analyst should de�ne the relationships that establish the hierarchyamong the classes in the model. In our representation we use the part-of and specialization-of relationshipsto represent the Whole-Part and Gen-Spec hierarchies respectively. Whole-Part relationships in the problemdomain may appear in any of the following variations: assembly-parts, container-contents, or collection-members. Most of the times the Whole-Part hierarchies are intuitively obvious to the analyst. But ifnecessary, each class can be examined to see if it could be regarded as a potential whole and if so what partsit would be connected to. Also, in a similar fashion, in order to de�ne the Gen-Spec relations each class canbe considered as a potential generalization to see if any of the other classes can be regarded as specializationsof that class.2.1.3 Identifying collaborations.The last step in the translation of the user's requirements is to complete the initial model including behavioral(dynamic) information of the problem domain. By focusing on object collaborations the analyst can identifythe behavior each object is responsible for exhibiting, thus de�ning the primary activities (services) and thelife history of each object.� Services. The has-service relationship of our semantic net representation is used to represent theactivities carried out by an object in the problem domain. We can identify activities by looking atverbs, attributes, predicates, and descriptive expressions in the requirements document.� OLH. The object-life-history relationship of our semantic net representation indicates the initial stateof the life history associated with an object. We provide the necessary constructs to model the objectlife history diagram of any object in the initial OORA model. Nodes represent object states, and therelationships represent state transitions. The conditions and actions involved in a transition must alsobe represented in the diagram.2.2 Re�ning the initial modelAt this point of the analysis, the requirements modeling activity no longer relies purely on the application ofnatural language analysis, domain knowledge, and general heuristics. Here the semantics associated with oursemantic net based representation is interpreted by a number of procedures that form part of an automatedsystem for OORA. This system facilitates the re�nement of the OORA model through a analyst-systemdialog intended to: (1) discover patterns among classes; (2) discover message-connections; (3) and discovergroups of cohesive classes. 4

2.2.1 Discovering patterns among classes.The �rst step in re�ning the initial requirements model involves a rationalization of the classes. Thisrationalization entails factoring out the common characteristics among classes and promoting general classes.To achieve this rationalization we need to discover patterns among classes. The procedures that implementthis capability suggest the creation of a new class when two classes or more are found that share some oftheir properties. If the user decides to create a new higher level class for a group of specialization classes,the system automatically constructs the new superclass based on the common properties and removes theseproperties from the specializations of that class. Additionally, the system infers whether a superclass mustbe de�ned as abstract or concrete. All the classes in the initial model are assumed to be concrete and asthe model is re�ned the supercalsses are de�ned as abstract or concrete depending on whether they covercompletely the properties of one or more of their specializations.2.2.2 Discovering message connections.A message connection exists between two objects when one object requires a service from another objectin order to ful�ll its responsibilities. The procedures of our automated system that implement this featureuse the dynamic information provided in the initial model to infer when a message connection between twoobjects must be de�ned. Such an inference is based on an analysis of the transitions de�ned in each objectlife history diagram. Every transition has conditions and actions associated. The actions are examined todetermine if an object needs one or more services from another object.2.2.3 Discovering groups of cohesive classes.By discovering groups of highly cohesive classes we can identify potential subjects in the problem domain.De�ning subjects is a way to organize our requirements model in partitions of related classes. The modulethat implements this analysis is based on an algorithm which examines the class hierarchies to determinethe uppermost classes. These classes are promoted as the �rst candidates to identify subjects in the model.Later the interdependencies and interactions between pairs of uppermost classes are analyzed to determinewhether these classes are cohesive. Interactions are found through an analysis of the message connectionsamong classes. Interdependencies are identi�ed by examining the class hierarchy from top to bottom todetermine whether two classes are related at any point in their hierarchies. The degree of interdependencebetween two classes is calculated and shown to the user which, based on domain knowledge, decides whichclasses must belong to which subject. 5

3 Representation of the OORA ModelThe representation used in our strategy is based on the knowledge representation scheme known as semanticnetwork or associative net [15, 16, 17]. Such a representation facilitates the codi�cation and use of the knowl-edge expressed in a requirements document. One important feature of this representation is its graphicalnotation which enhances its understandability. This graphical notation consists of nodes and links. Nodescan represent classes or the characteristics related to them, and links express the associations between them.Our representation comprises a set of valid links or relationships that are the building blocks of the semanticnetwork. This graphical notation is mapped to a data structure that is used as the internal representationin our implemented system. Such an internal representation involves a collection of data structures knownas templates each of which is a group of slots and multislots with their associated values. These templatesrepresent the classes in the OORA model. The slots of each template represent the relationships betweena class and the characteristics of that class. The value or values of a slot can be interpreted as pointers toother templates, or simply as properties of the class represented in the template to which that slot belongs.In the graphical notation for this internal representation, a template is depicted as a node with a set ofarcs emanating from it. The slot names appear as labels on the arcs, and the slot values appear at the arcsterminus.The labels on the arcs can be any of the following:� has-characteristic. Indicates a relationship between a class and its associated attributes.� has-service. Speci�es a relationship between a class and the processing that class is responsible for.� specialization-of. Represents the Gen-Spec relationship between two classes.� part-of. This relationship is used to represent the Whole-Part relationship between two classes.� message-connection. Indicates a service request from one object to another.� object-life-history. This relationship is the link between an object and its object life history diagramrepresented in a semantic net fashion. This link points to the initial state of the OLHD de�ned for agiven object� abstract. The allowed values for the nodes to which this relationship is connected are yes or no,indicating whether or not a class is abstract. If the value is no, then the class is interpreted asconcrete. In the initial model all the classes are assumed to be concrete.6

� subject. Indicates an association between a class and the subject to which that class belongs.The whole set of relationships is used in the development of an OORA model according to our strategy.However, in the �rst step which entails creating an initial model, only a few of these relationships areneeded, the rest of them are used while the model is being re�ned. Since this re�nement is carried out byan automated system, the manipulation of these relationships is transparent to the user.Our semantic net representation of the user requirements also allows us to specify the life history diagramfor any object in the model. The link between an object and its life history diagram is speci�ed throughthe object-life-history relationship just described. In the graphical representation of an OLHD nodes areinterpreted as object states and the arcs are interpreted as state transitions. The data structure that is usedas the internal representation of this graphical notation requires the conditions and actions involved in thetransitions to be speci�ed.The semantics of our representation are de�ned by a group of specialized production rules that manipulatethe internal representation in various ways. The inferences provided by these rules are reduced to basicanalyses on the data structure that focus on object-oriented requirements analysis issues.4 ImplementationWe have developed a rule-and-function based software system to support our OORA strategy. The systemwas implemented using CLIPS version 6.0, a knowledge-based system development tool that integratesfeatures of three software development paradigms, rule, procedural, and object-oriented. CLIPS is a forward-reasoning system based on a pattern matching algorithm. Figure 2 shows the structure of the implementationof the object-oriented requirements analysis system. The system provides automated assistance to extractan OORA model from the user requirements expressed in a semantic network representation.Our implementation consists of three modules each of which manipulates the OORA model in di�erentways. User's requirements expressed in a semantic network model are input to the system, then, the systeme�ects a number of analysis on that input oriented to infer the details of the �nal OORA model. The nodesand relationships of the semantic network are represented through templates. Functions (de�untions), globalvariables, and groups of rules organized through modules are used to control the execution of the systemand to implement the analysis required to discover common patterns among classes, to identify messageconnections, and to detect groups of cohesive classes. The same data structure of the initial model plussome characteristics added through the automated analyses constitute the output of the system. These7

user identification of message

connections

identification of cohesive

classes

patterns among classes

identification of common

knowledge base

fact

base

OORA system

final model

initial model

A

B

CFigure 2: Structure of the knowledge-based system for OORA.analyses are carried out through a sequence of questions and answers where the user participates to elicit themodi�cations to the OORA model. To make such elicitation the user must apply the heuristics recommendedin section 4.3 according to the systems' domain.The analyses performed by each module of the system can be described in general as follows:Module A: Identi�cation of common patterns� ask for the list of classes to be analyzed� estimate the intersection of the attributes and services of the classes in that list� if the intersection turns out to be non empty then do the following:{ suggest creating a new general class for the classes being analyzed{ ask the user to validate the creation of a new class{ annex a new class to the model with the properties shared by the classes being analyzed{ rede�ne the classes being analyzed by factoring out their common properties{ de�ne those classes as specializations of the class just created{ determine whether the new class is abstract or concrete8

Module B: Identi�cation of message connectionsfor any object in the model whose OLHD diagram has been de�ned:� analyze every transition in the OLHD of that object� analyze every action associated with every transition� determine whether any action is a request of a service from other object in the model� if so, then establish a message connection between the object requesting the service and the objectthat provides the service requestedModule C: Identi�cation of groups of cohesive classesThe primary purpose of this analysis is to discover potential subjects corresponding to groups of highlycohesive classes. The analysis is based on the interdependencies and the interactions among the classes inthe model.� interactions among classes correspond to the message connections between any pair of classes� interdependencies among classes are determined through an analysis of the Whole-Part and Gen-Specstructures. Such an analysis is performed as follows:{ identify the uppermost classes{ for any pair of uppermost classes calculate their degree of interdependence as follows:� for each of the two classes identify the set of classes in their Gen-Spec hierarchy and theclasses in their Whole-Part hierarchy� the intersection of the two sets determines the degree of interdependence between the twouppermost classes� the assignment of a class to a particular subject is done by the user according to the interactions andinterdependencies of that class, and according to the problem domain.5 ExampleIn this section we illustrate the details of our strategy by means of an example. Consider the followingrequirements text which was adapted from an example presented in the OOA book written by Coad andYourdon [6]. 9

Example: registration and title systemProblem statement: The problem consists of developing a motor vehicle registration and titlesystem. The required system should maintain information on the following:organization { name, manager, address, telephone.clerk { legal name, address, user name, authorization. Each clerk belongs to an organization.Clerks are accountable for registrations and titles issued (plus the fees accepted)owner { legal name, address, telephonetitle { date and time, number, ownership evidence, surrendered title. Every time a new title isdeveloped, a fee for that particular title is calculated and accepted. Some information about thevehicle and its owner needs to be accessed to perform the calculation of the corresponding titlefee.registration { date and time, date and time start, date and time end, plate, sticker. As in hedevelopment of a title, every time a new registration is developed, a fee must be calculated andaccepted, and some information about the vehicle and its owner needs to be accessed to performthe calculation of the corresponding registration fee. In addition, the system is required to checkfor registration renewals.The system should maintain information about the following types of vehicles:sedans { number, year, costtrucks { number, year, model, cost, number of passengers, mileage, powered by, temporary grossweighttrailers { number, year, model, cost, gross weightmotorcycles { number, year, model, cost, passengers, mileageWe shall show how this requirements text can be transformed to an object-oriented requirements modelusing our strategy. Appendix A illustrates the requirements models generated for the above example.5.1 Extracting an initial model from the requirements documentWe start by developing an initial model for the title and registration system expressed in a form of semanticnet using the relationships has-characteristic, has-service, part-of, and object-life-history.10

5.1.1 Identifying potential classes.Potential classes include another systems (sedan, truck, trailer, motorcycle), events remembered (title, reg-istration), roles played (clerk, owner), and an organizational unit (organization). The following classes andassociated attributes can be identi�ed from the requirements:|an organization has name, manager, and telephone|clerks are characterized by legal name, address, user name, and authorization|an owner has legal name, address, and telephone|a title is distinguished by date and time, number, ownership, evidence, and surrendered title|registrations have date and time, date and time start, date and time end, plate, and sticker|sedans are distinguished by number, year, model, and cost|trucks are distinguished by number, year, model, cost, number of passengers, mileage, poweredby, and temporary gross weight|trailers are distinguished by number, year, model, cost, and gross weight|motorcycles are distinguished by number, year, model, cost, number of passengers, and mileageFigure 3 illustrates how this information can be represented in a semantic network applying the has-characteristic relationship.5.1.2 Identifying structures.The following information related to Whole-Part and Gen-Spec structures can be deduced from the require-ments:|a clerk belongs to an organization (Whole-Part)|persons involved in the system include clerks and owners (Gen-Spec)|titles and registrations are both legal events (Gen-Spec)|vehicles include sedans, trucks, trailers, and motorcycles (Gen-Spec)The above information about Gen-Spec structures will not be needed until the re�nement of the model.At this stage we concentrate on Whole-Part structures. Figure 4 shows how these Whole-Part structures arerepresented using the part-of relationship of our notation.11

Oraganization

Name Message Address Telephone

Title

OwnershipEvidenceNumberDateTime

TitleSurrendered

Clerk

LegalName Address UserName Authorization DateTime DateTimeStart DateTimeEnd StickerPlate

Registration

Truck

Number

Year

Model

Cost

Passengers

Mileage

PoweredBy

Temp

Number

Year

Model

Cost

Passengers

Mileage

Motorcycle

Trailer

Number

Year

Model

Cost

GrossWeight

Sedan

Number

Year

Model

Cost

hc hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

hc

TelephoneAddrressLegalName

Owner

hchchc

hc = has-characteristic

hc hc hchc hc

hc hc

hc hc hc hc hc hc hc hc

hc

hc

Figure 3: Classes and attributes12

Oraganization

Name Message Address Telephone

Clerk

LegalName Address UserName Authorization

po

po = part-ofhc = has-characteristic

hchc

hchchc hc

hchc

Figure 4: Whole-Part structure5.1.3 Identifying collaborations.The requirements text suggests the following information about the collaborations between objects, and theprocessing that each object is responsible for:|for every title a fee must be calculated and accepted|for every registration a fee must be calculated and accepted|registrations are checked for renewal|in order to calculate a title or registration fee some information from the vehicle and its ownermust be accessedFigure 5 illustrates the graphical representation of this information using the has-service relationship toexpress an association between an object and its services.Figure 6 shows the OLHD for the title and registration objects indicating the object states and thetransitions from one state to another in terms of conditions-actions.13

DateTime DateTimeStart

Registration

DateTimeEnd Plate Sticker

CheckRenewal

AcceptFee CalculateFee

hs

hs

hchchchchc

hs

DateTime Number

Title

hc hc hchc

AcceptFee CalculateFeehs hs

hs = has-service

hc = has-characteristic

SurrenderedTitleEvidence

Ownership

Figure 5: Classes, attributes, and servicesCalculateFee

Access OwnerAccess Vehicle

ShowFee

Access Title

Access Title

olh

CalculatingFee AcceptingFee

Idle

Access Registration

CheckRenewalAccess Registration

AcceptFee

Access OwnerAccess Vehicle

Calculate Fee

ShowFee Access Registration

Access RegistrationAcceptFee

olh

CheckingRenewal

AcceptingFeeCalculatingFee Idle

Registration

olh = object-life-history

Title

Figure 6: Object life history representation14

5.2 Re�ning the initial modelAt this stage, the semantic net representation of the initial model is mapped to the internal representationof the OORA system and loaded into the system. Further modi�cations to the model are made through aninteraction with the system.5.2.1 Discovering patterns among classes.In the requirements text four types of vehicles are mentioned (i.e. sedans, trucks, trailers, and motorcycles).Suppose that we want to know what are their common properties to create a higher level class with theproperties shared by the four classes. We can do that using the module designed to identify commonpatterns among classes. A dialog with the system to create a class named Vehicle would look like this.The current classes in the OORA model are:(Motorcycle Trailer Truck Sedan Registration Title Owner Clerk Organization)What classes would you like to consider in the analysis ?Sedan Truck Trailer MotorcycleThose classes share the following properties:Attributes: (Cost Model Year Number)Do you want to create a general class for those classes (yes/no) ? yesWhat will be the name of that general class ? VehicleA new superclass has been created with the following properties:Name: VehicleAttributes: (Cost Model Year Number)Abstract: NoThe creation of the class Vehicle causes several changes in the model. The class Sedan is removed fromthe model and the class Vehicle is de�ned as concrete because it has all the attributes de�ned in the classSedan. These inferences are automatically made by the system. Figure 7 shows how the model is modi�edafter the creation of the class Vehicle.Two classes of persons that play di�erent roles in the system can be identi�ed from the requirements,these are the clerks and the owners. Suppose we want to discover the common patterns among those two15

MileagePassengers

Motorcycle

TempGrossPoweredByMileagePassengers

Truck

Trailer

GrossWeight

Number

Year Model

Cost

Vehicle

hc

hc hc

hc

hc hchc

hchchc

spo

spo

spo

hc

spo = specialization-of

hc = has-characteristicFigure 7: OORA model after the class Vehicle is createdclasses and create a higher level class named Person. A dialog with the system to do that would look likethis. The current classes in the OORA model are:(Vehicle Motorcycle Trailer Truck Registration Title Owner Clerk Organization)What classes would you like to consider in the analysis ?Clerk OwnerThose classes share the following properties:Attributes: (Address LegalName)Do you want to create a general class for those classes (yes/no) ? yesWhat will be the name of that general class ? PersonA new superclass has been created with the following properties:Name: PersonAttributes: (Address LegalName)Abstract: YesFigure 8 illustrates how these modi�cations will a�ect the model.16

hc hc

hc

Person Address

Owner

TelephoneAuthorizationUserName

Clerk

LegalName

spospo

hchc

spo = specialization-of

hc = has-characteristicFigure 8: OORA model after the class Person is createdThe requirements text also indicates two classes of legal events, namely the development of a title and thedevelopment of a registration. Applying the procedure described above to create a class named LegalEvent,causes the following interaction with the system.The current classes in the OORA model are:(Person Vehicle Motorcycle Trailer Truck Registration Title Owner Clerk Organization)What classes would you like to consider in the analysis ?Registration TitleThose classes share the following properties:Attributes: (DateTime)Services: (AcceptFee CalculateFee)Do you want to create a general class for those classes (yes/no) ? yesWhat will be the name of that general class ? LegalEventA new superclass has been created with the following properties:Name: LegalEventAttributes: (DateTime)Services: (AcceptFee CalculateFee)Abstract: No 17

hc

hc

hchchc

spo

spo = specialization-of

hc = has-characteristic

hc hc hc

spo

hs

hs

hs

DateTime

Title

NumberOwnershipEvidence Title

SurrenderedStickerDateTimeEnd PlateDateTimeStart

CheckRenewal

Registration

LegalEvent

AcceptFee

CalculateFee

hs = has-service Figure 9: OORA model after the class LegalEvent is createdSENDER RECEIVER REQUESTED SERVICELegalEvent Vehicle AccessLegalEvent Owner AccessTable 1: Message connections.After this dialog the internal representation of the model is modi�ed as shown in �gure 95.2.2 Discovering message connections.In our example, two classes require services from other classes. The class Title involves a responsibility whichdemands services from the classes Vehicle and Owner. Similarly the class registration requires services fromthe classes Vehicle and Owner. An execution of the module designed to discover message connections willinfer the information shown in table 1.The system identi�es the message connections of the class LegalEvent instead of the message connectionsof the classes Title and Registration because LegalEvent is the generalization of those classes. Figure 10shows how these message connections are attached to the corresponding classes in the model.5.2.3 Discovering groups of cohesive classesWe should apply the guidelines discussed in section 4.3 to organize the classes of our model in subjectsof closely related classes. The �rst step in this identi�cation consists of promoting the uppermost classes18

mc

LegalEvent

VehicleOwner

mc

mc = message-connectionFigure 10: Message connections in the OORA modelTHE CLASSES THAT ARE NOT IN ANY STRUCTURE ARE: NoneTHE UPPERMOST CLASSES ARE: Vehicle LegalEvent Person OrganizationTable 2: Uppermost classes and classes not in a structureand detecting the classes that are not related to any other class. Our implemented system can infer thisinformation from the requirements model as shown in table 2.At this point we may wish to know which classes are interactive. The OORA system provides us withthe information shown in table 3We might also want to identify the interdependences between any pair of uppermost classes. One objectiveof our implemented system is to generate, organize and represent these interdependences in a meaningfulway to help the software analyst identify those classes that should be modeled as groups of cohesive classes.The analysis of interdependences between pairs of uppermost classes of our example produces table 4.The analyst is required to interpret this information and apply it to assign any class to a particularsubject. This is the last step in the identi�cation of subjects.CLASS INTERACTS WITH THE CLASS(ES)LegalEvent Owner VehicleTable 3: Analysis of interactive classes19

Uppermost Classes in the Gen-Spec and Common Degree ofclasses Whole-Part hierarchies classes interdependenceLegalEvent Registration TitleVehicle Truck Trailer Motorcycle 0.0Person Owner ClerkVehicle Truck Trailer Motorcycle 0.0Person Owner ClerkLegalEvent Registration Title 0.0Organization ClerkVehicle Truck Trailer Motorcycle 0.0Organization ClerkLegalEvent Registration Title 0.0Organization ClerkPerson Owner Clerk Clerk 0.2Table 4: Analysis of interdependence between pairs of uppermost classesReferences[1] S. Shlaer and S. Mellor, Object-oriented systems analysis: modeling the world in data. Yourdon Press,1988.[2] D. de Champeaux, D. Lea, and P. Feaure, Object-Oriented Systems Development. Addison-wesleypublishing company, 1993.[3] M. Rumbaugh and M. Premerlani, Object-Oriented Modeling and Design. Prentice Hall, 1991.[4] A. Wasserman, P. Pircher, and R. Muller, \The Object-Oriented software design notation for softwaredesign representation," IEEE Computer, vol. 23, 1990.[5] J. Martin and J. O. James, Object-Oriented Analysis and Design. Prentice Hall, 1992.[6] P. Coad and E. Yourdon, Object-oriented analysis. Yourdon Press, second ed., 1991.[7] S. Adiga, Object-Oriented Software for Manufacturing Systems. Chapman and Hall, 1993.[8] L. Garceaw, E. Jancura, and J. Kneiss, \Object-Oriented Analysis and Design: a new approach tosystems development," Journal of Systems Management, Jan 1993.[9] G. Heidorn, Readings in Arti�cial Intelligence and Software Engineering, ch. Automatic ProgrammingThrough Natural Language Dialog: a survey. Morgan Kaufman Publishers, Inc., 1986.[10] G. Booch, Object-oriented design with applications. The Benjamin/Cunmings publishing company, inc.,1991. 20

[11] I. Jacobson, M. Christerson, P. Jonsson, and G. Overguard, Object-oriented software engineering: a usecase driven approach. Addison Wesley, 1992.[12] S. Shlaer and S. Mellor, Object life cycles : modeling the world in states. Yourdon Press, 1992.[13] R. Abbot, \Program design by informal english descriptions," Communications of the ACM, Nov 1983.[14] B. Belkhouche and J. Kozma, \Semantic Case Analysis of Informal Requirements." Proceedings of theFourth Next Generation CASE Tools, La Sorbonne, Paris, June 1993.[15] M. R. Quilian, Semantic Information Processing. Cambridge, MA.: M. Minsky (ed). MIT Press, 1968.[16] J. Mylopoulos and H. Levesque, On Conceptual Modeling, ch. An Overview of Knowledge Representa-tion, pp. 4{17. Springer-Verlag, 1984.[17] W. Morris, Arti�cial Intelligence : a knowledge-based approach, ch. Knowledge Representation, pp. 274{303. Boyd and Fraser, 1988.

21