System and method for interactively transforming a system or process into a visual representation5838973Abstract A computerized modeling system is provided. The present invention is a computer-implemented, interactive, real-time software tool, for physically transforming a system or process into a visual representation. The software tool includes a class developer for interactively developing the visual representation in real time. The visual representation is physically embodied in a computer-readable medium for visualization on a computer display device, and includes at least one of a class, a class behavior, a class attribute, a collaboration, and a collaboration message flow. The software tool also includes a three-dimensional visual representation module for displaying a three-dimensional depiction of the visual representation on the display device. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
______________________________________
SYSTEM REQUIREMENTS ENTERED INTO DOCUMENT
______________________________________
For each segment of the requested
reservation, the system tries to find a flight
that meets the requested schedule, and find a
flight that has enough available seats to satisfy
the reservation request. Priority is given to the
preferred carrier. If a flight matches the
requirements, but has no available seat, it is
determined if the customer wants to be put on the
waiting list for that flight. The customer can be
a member of the. frequent traveler program of the
carrier, in which case his or her request is put
in the frequent traveler waiting list, otherwise
it is put in the regular waiting list.
______________________________________
When this information has been entered, the done button 224 in the parse and clarify dialog window 220 is selected to return the user to the process map window 170. The parse & clarify process icon 172 in FIG. 4 is then marked, letting the user know that this step has been carried out. The user may, however, return to the parse and clarify step 192 of FIG. 5 by selecting the parse & clarify process icon 172 at any time. Selecting the object process icon 174 of FIG. 4 allows the user to identify potential objects after the system requirements have been clarified. The result of identifying potential objects will be a group of classes for the model. Upon selecting the object process icon 174, the identifying objects dialog window 230 of FIG. 9 is provided. The document of Table 1 is then loaded into the word processing application to identify the potential objects. This is accomplished by selecting button 232 of the identifying objects dialog window 230, which again activates the word processing application. Object words in the system requirements document of Table 1 can be tagged to identify the various classes of the system model. In the preferred embodiment, these objects are tagged by boldfacing potential objects in the system requirements document. Table 2 shows the system requirements of the word processing document after having been tagged by boldfacing the potential system objects.
TABLE 2
______________________________________
SYSTEM OBJECTS TAGGED IN DOCUMENT
______________________________________
For each segment of the requested
reservation, the system tries to find a flight
that meets the requested schedule, and find a
flight that has enough available seats to satisfy
the reservation request. Priority is given to the
preferred carrier. If a flight matches the
requirements, but has no available seat, it is
determined if the customer wants to be put on the
waiting list for that flight. The customer can be
a member of the frequent traveler program of the
carrier, in which case his or her request is put
in the frequent traveler waiting list, otherwise
it is put in the regular waiting list.
______________________________________
When the system objects have been tagged as shown in Table 2, the done button 234 in the identifying objects dialog window 230 of FIG. 9 is then selected to return the user to the process map window 170. The object parsing dialog window 240 is presented to the user upon clicking the done button 234 as shown in FIG. 10. The object parsing dialog window 240 allows the user to import the document of Table 2 which has its potential business objects tagged as boldfaced words. If no document is to be imported, the user selects the no button 242 to close the object parsing dialog window 240. Upon clicking the yes button 244 in the object parsing window 240, the open file window 250 of FIG. 11 is provided to allow the user to select the file name of the word processing document created from the text of Table 2. The desired file name is selected by selecting the name of the file in the file list field 252 after selecting the appropriate directory from the directory list field 254, and selecting the OK button 256. FIG. 12 is a depiction of the quick tips window 260. The quick tips window 260 is provided to the user the first time the object process icon 174 is selected and the user has opened a document from the file open window 250 or has chosen not to import a document by selecting the no button 242 in the object parsing dialog window 240. The quick tips window 260 informs the user of useful features used in identifying objects, and provides guidance on how to implement the corresponding menu, toolbar or keystroke command. FIG. 13 shows object window 270 which depicts a number of objects in a two-dimensional form. Each of the objects which were tagged in the document of Table 2 are separately presented as a two-dimensional object in 2D object window 270. Four object tools are shown in the 2D object toolbar 272. The pointer object tool 274 allows the two-dimensional objects in 2D object window 270 to be moved from their current locations to new locations in the 2D object window 270. The text object tool 276, when selected, allows the user to enter text into 2D object window 270. The new object tool 278, when selected, allows the user to add new objects in addition to the current objects in 2D object window 270. The link object tool 280, when selected, allows the user to draw lines connecting certain objects to show a relationship between those connected objects. Upon selection of the new object tool 278, the class editor window 290 of FIG. 14 is provided. Class name entry field 292 allows the user to enter the name of the new class, which is shown as "ticket" in FIG. 14. A description of this class can be entered in the class description field 294. A new object will be entered in the 2D object window 270 upon selecting the OK button 296 in the class editor window 290. FIG. 15 illustrates the ability of objects in 2D object window 270 to be added and moved. The ticket object 300 created by the class editor window 290 of FIG. 14 is shown in 2D object window 270. Objects have been moved by selecting the pointer object tool 274 in the 2D object toolbar 272, selecting the desired object with the cursor arrow 302, and moving the selected object to a new location. Some of the objects in 2D object window 270 are also shown to be linked. This is accomplished by selecting the link object tool 280, and selecting two objects to be linked. The carrier object 304 of FIG. 15 is linked to the seats object 306, which is in turn linked to the waiting list object 308. The reservation object 310 is shown linked to the customer object 312. The flight object 314 is linked to the customer object 312, the waiting list object 308, and the schedule object 316. Linking is performed when the link object tool 280 is selected, a first object is selected by clicking on the object in the 2D object window 270, and clicking on a second object to be linked. This linkage shows that there is some relationship between the linked objects. The OTV software tool provides various graphics options to change or enhance the 2D object window 270. These graphics options can be selected by way of the different user inputs, including menu-driven input, toolbar input, and keystroke input. The various options include fill patterns, pen styles, colors, alignment and fonts. Using these and other options allow the visual depiction in the 2D object window 270 to be set or changed at the user's preference. The OTV software tool also includes various viewing options, which also can be selected by way of the different user inputs, including menu-driven input, toolbar input, and keystroke input. The viewing options include toggle switches for viewing the status bar 150 shown in FIG. 2, the 2D object toolbar 272, and a visual grid. A "snap-to-grid" toggle function is also provided to ease alignment and movement of the objects. A three-dimensional viewing window is provided by the OTV software tool. Viewing the object model in three dimensions allows users to view their model quantitatively, and interactions between the objects are brought to life. A three-dimensional view of the 2D object window 270 can be initiated by way of any of the different user inputs. Referring now to FIG. 16, the 3D object window 320 is shown. The 3D object window 320 is shown concurrently with the 2D object window 270 to form a split image in a single object window 322. The 3D object window 320 provides a three-dimensional view of 2D object window 270, as the same objects and their relative positions in the 2D object window 270 are shown in three dimensions in the 3D object window 320. A 3D object toolbar 324 in object window 322 allows the user to move through the 3D object window 320, in order to view the objects from various vantage points. Each of the objects defined in Table 2, and shown in 2D object window 270 and 3D object window 320, represent a class within the system model. A class is defined by its collective responsibilities, including its attributes and behaviors. By describing the responsibilities of each class, the role that each class plays is defined within the system model. Referring briefly to FIGS. 4 and 5, step 196 of identifying and assigning responsibilities to the classes is initiated by selecting the responsibilities process icon 176. Selection of the responsibilities process icon 176 opens the assigning responsibilities dialog window 330 as shown in FIG. 17. The assigning responsibilities dialog window 330 allows the user to tag the actions that each of the classes are responsible for providing. The word processor can again be initiated by clicking on button 332 in the assigning responsibilities dialog window 330. The system requirements in the document are again tagged, this time tagging the actions of each class. In the preferred embodiment, the tagging of the actions of each class is accomplished by italicizing action phrases associated with each of the objects. The action phrases could alternatively be tagged in other ways without departing from the scope of the invention, such as underlining, capitalization, etc. The tagging of action phrases can be seen in Table 3, where the actions have been tagged by italicizing various phrases. The italicized words are also underlined for illustrative purposes in Table 3 to allow the tagged phrases to be seen more clearly in the table.
TABLE 3
______________________________________
CLASS RESPONSIBILITIES TAGGED IN DOCUMENT
______________________________________
For each segment of the requested
reservation, the system tries to find a flight
that meets the requested schedule, and find a
flight that has enough available seats to satisfy
the reservation request. Priority is given to the
preferred carrier. If a flight matches the
requirements, but has no available seat, it is
determined if the customer wants to be put on the
waiting list for that flight. The customer can be
a member of the frequent traveler program of the
carrier, in which case his or her request is put
in the frequent traveler waiting list, otherwise
it is put in the regular waiting list.
______________________________________
When the document has been changed to tag each of the class responsibilities, the done button 334 in the assigning responsibilities dialog window 330 is selected, indicating that the tagging is complete, and closing the assigning responsibilities dialog window 330. FIG. 18 shows the action parsing dialog window 340, presented upon selecting the done button 334 of the assigning responsibilities dialog window 330, which allows the user to import the document with the tagged class responsibilities shown in Table 3. The user has the option of not importing the document by selecting the no button 342, whereby the user would manually enter the class responsibilities. Otherwise, the user selects the yes button 344 in the action parsing dialog window 340 to import the document having the tagged class responsibilities. The OTV software tool recognizes the tagged, italicized action phrases, and automatically enters those phrases into a responsibility list of the recipient list window 350 of FIG. 19. FIG. 19 shows the recipient list window 350, having a responsibility list 352, a class list 354 and a behavior name list 356. When the user selects the yes button 344 in the action parsing dialog window 340, the individual tagged action phrases are automatically entered into the responsibility list 352. The responsibilities listed in the responsibility list 352 are each assigned to a class, which is entered into the class list 354. Each of the responsibilities listed in the responsibility list 352 are also assigned a behavior name in the behavior name list 356, which provides a name for the corresponding responsibility. As seen in FIG. 19, the 2D object window 270 can be shown simultaneously with the recipient list window 350 to assist the user in defining the classes and behaviors. FIG. 20 further illustrates that the 3D object window 320 can also be simultaneously displayed with the 2D object window 270, and the recipient list window 350. The three-dimensional view provides immediate feedback to the user when assigning behavior names to classes, as will be shown in more detail below. Each of the tagged responsibilities in the responsibility list 352 is assigned to a particular class, where each class represents one of the objects in 2D object window 270 and 3D object window 320. FIG. 20 illustrates how classes are assigned to each of the responsibilities in the responsibility list 352. A class can be directly entered into each field of class list 354, or can be selected from a pull-down list 358 of classes displayed by clicking on the pull-down button 360, and clicking on the desired class in the pull-down list 358. Each of the responsibilities in the responsibility list 352 can similarly be assigned to a class. Referring now to FIG. 21, the recipient list window 350 is shown having a completed responsibility list 352, class list 354, and behavior name list 356. Each of the responsibilities in the responsibility list 352 has been assigned to a class in the class list 354. Behavior names associated with the responsibilities in the responsibility list 352 are shown in the behavior name list 356. Each of the behavior names in the behavior name list 356 is a user-generated name that the user creates to identify one of the responsibilities in the responsibility list 352. Behaviors describe the capabilities that a particular class can provide. A behavior is a method associated with a class that defines the responsibility of that class. For instance, in the responsibility field 362, the responsibility is to "find a flight that meets the requested schedule". The item being acted on is the schedule, which represents the class, and the behavior associated with that responsibility for that class is named "FindFlight" in behavior field 364. As the user adds behavior names to each of the classes, the behaviors are dynamically added to the classes in the 3D object window 320. For example, the class labeled "waiting list" in class list 354 has three behaviors associated with it in behavior fields 366, 368, and 370. These behaviors are respectively labeled IsWaitingList, IsFreqWaitingList, and IsRegWaitingList. These behaviors are dynamically added to the three-dimensional view of the waiting list class in the 3D object window 320. The classes are shown in the 3D object window 320 as three-dimensional "cells", which are the three-dimensional representations of the two-dimensional "objects" in the 2D object window 270. The waiting list cell 372 shows the corresponding behaviors in behavior blocks 374, 376 and 378. The waiting list cell 372 can be dynamically brought into the view shown in FIG. 21 by clicking on the waiting list cell 372 from any view within the 3D object window 320. FIG. 22 illustrates how new classes can be added during the responsibility design stage. By selecting the new object tool 278 in the 2D toolbar 272 in 2D object window 270, the class editor window 290, previously shown in FIG. 14, is opened. The name of the new class is then entered into the class name entry field 292, and a description of the new class is entered into the class description field 294. The new class object 380 is shown in the 2D object window 270, and is also shown as a new class cell 382 in the 3D object window 320. Selection of the pointer object tool 274 in the 2D toolbar 272 allows the new class object 380 to be moved within the 2D object window 270, which will simultaneously move the three dimensional new class cell 382 in the 3D object window 320. Similarly, moving the cells in the 3D object window 320 automatically moves the objects represented in the 2D object window 270. Returning now to FIGS. 4 and 5, step 198 of FIG. 5 is initiated by selecting the descriptions process icon 178 of FIG. 4. Step 198 allows the user to describe the classes and their behaviors to clearly define the rule of each class in the model and to define the services that it provides. Upon selecting the descriptions process icon 178, the desired system model can be captured in the 2D object window 270 of FIG. 23. The system model in FIG. 23 has seven objects, including the customer object 390, the reservation object 392, the segment object 394, the carrier object 396, the flight object 398, the seat object 400, and the waiting list object 402. When these objects have been defined after performing steps 192, 194 and 196 in the flow chart of FIG. 5, the user can further define and describe the classes and their behaviors. Referring now to FIG. 24, the objects in the 2D object window 270 are also shown as three dimensional cells in the 3D object window 320. The pointer object tool 274 in the 2D object toolbar 272 (shown in FIG. 13) allows objects to be moved within the 2D object window 270. The cells in the 3D object window 320 can also be moved within the 3D object window 320 by selecting and moving the desired cell, which can be accomplished by clicking on the desired cell and "dragging" it to a new location. FIG. 24 also illustrates the relationship between the locations of the two-dimensional objects in the 2D object window 270 and the locations of the three-dimensional cells in the 3D object window 320. The customer object 390 is shown located to the left of the reservation object 392 in the 2D object window 270. The segment object 394 is positioned directly in front of the reservation object 392. In the 3D object window 320, it can be seen that the three-dimensional customer cell 410 is located to the left of the reservation cell 412, and the segment cell 414 is positioned directly in front of the reservation cell 412. Therefore, the relative positions of the objects in the 2D object window 270 parallel the relative positions of the cells in the 3D object window 320. Referring now to FIG. 25, it can be seen that a change of location in the 2D object window 270 simultaneously changes the locations of the cells in the 3D object window 320. Through the use of the pointer object tool 274, the reservation object 392 has been moved to the left, to the original position of the customer object 390. The customer object 390 has been moved to the right, to a point beyond the original position of the reservation object 392. The segment object 394 has been moved to the left so that it is located in front of, and approximately between, the reservation object 392 and the customer object 390. The customer cell 410, the reservation cell 412, and the segment cell 414 in the 3D object window 320 have also been automatically repositioned according to the new locations in the 2D object window 270. The reverse is also true, that is, repositioning of the cells in the 3D object window 320 automatically repositions the objects in the 2D object window 270. The attributes and behaviors associated with each class can be modified within the 2D object window 270 or the 3D object window 320. In the preferred embodiment of the 2D object window 270, the attributes and behaviors associated with a particular class can be modified by double-clicking on the desired object when the pointer object tool 274 is selected. In the preferred embodiment of the 3D object window 320, the attributes and behaviors associated with a particular class can be modified by double-clicking on the desired cell. Selecting the desired object or cell in the above manner presents the class editor window 290 for the selected class, where modifications to the class can be performed. FIG. 26 shows the class editor window 290 for a selected class. Where an object or cell is selected from the 2D object window 270 or the 3D object window 320, the class editor window 290 is presented having all associated information for that class which was entered into the recipient list window 350. For example, FIG. 26 displays the class editor window 290 where the reservation cell 412 was selected from the 3D object window 320. The class editor window 290 is the same class editor window 290 of FIG. 14, except that an option within the class editor window 290 has been selected. The class editor display button 420 in the class editor window 290 allows the user to toggle between displaying an abbreviated version of the class editor window 290 as shown in FIG. 14, and the full version as shown in FIG. 26. Selecting the class editor display button 420 when the full version of the class editor window 290 is displayed reduces the class editor window 290 to its abbreviated version shown in FIG. 14. The abbreviated version is accomplished by hiding the lower portion of the class editor window 290 that includes the overview tab 422, the attributes tab 424, and the behaviors tab 426. Selecting the class editor display button 420 again would restore the full display as shown in FIG. 26. The class editor window 290 of FIG. 26 includes the class name entry field 292, which automatically presents the name of the class associated with the object or cell selected from the 2D object window 270 or the 3D object window 320 respectively. The selected class for this case is the "reservation" class. The class description field 294 includes a description of the reservation class. The user can select any one of the overview tab 422, the attributes tab 424 and the behaviors tab 426. In FIG. 26, the attributes window 428 is shown, which is presented upon selection of the attributes tab 424. Selection of the attributes tab 424 presents an attribute name field 430, and an attribute descriptions field 432 in the attributes window 428. The attribute name field 430 allows the user to enter a new attribute for the reservation class, or view an existing attribute. A description of the attribute is presented in the attribute description field 432. In the example of FIG. 26, a new attribute has been added to the reservation class. The attribute has been named "date" in the attribute name field 430, and is described in the attribute description field 432 as "This holds the date requested". To enter this new attribute, the new button 434 in attribute window 428 is selected. The user can also decide not to enter the new attribute by selecting the cancel button 436. Existing attributes and their descriptions can be viewed by selecting the attribute pull-down button 438, which provides a selectable list of the current attributes associated with the class. The class editor window is closed with changes saved by selecting the OK button 296, and is closed without saving changes by selecting the cancel button 420. FIG. 27 shows the behaviors window 450 which is presented upon selection of the behaviors tab 426 from the class editor window 290. A new behavior can be entered in the behavior name field 452, or an existing behavior can be entered in the behavior name field 452 by selecting the behavior pull-down button 454 and selecting an existing behavior from a list of existing behaviors. In the example of FIG. 27, an existing behavior labeled "AcceptSegment" has been selected in the behavior name field 452. A description of the behavior in the behavior name field 452 is provided in the behavior description field 456. The returns field 458 allows the user to describe the return value of the behavior named in the behavior name field 452. The collaborators field 460 is automatically filled out for the behavior named in the behavior name field 452 based on information provided during the collaboration step. Each of the entries in the collaborators field 460 represents an interaction from the class named in the class name entry field 292 to the class named in the particular entry in the collaborators field 460. The behaviors associated with of the classes in the collaborators field 460 are also listed. For example, an entry in the collaborations field 460 which reads "Carrier::ProvideFlightList" represents an interaction from the reservation class named in the class name entry field 292 to the carrier class. The behavior associated with this interaction is the "ProvideFlightList" behavior. The returns field 458 and the collaborators field 460 will be described in more detail in connection with the description of the interaction diagrams described below. New behaviors and their descriptions are entered by the user into the behavior window 450. A new behavior name is entered into the behavior name field 452, and a description and a return value are then entered into the behavior description field 456 and the returns field 458 respectively. The new behavior is accepted upon selection of the new button 462. Any of the existing behaviors, which are presented upon selection of the behavior pull-down button 454, can be deleted from the system by selecting the delete button 464 in the behaviors window 450. Referring now to FIG. 28, the overview window 470 of the class editor window 290 is shown. Selection of the overview tab 422 presents an attribute list 472 and a behaviors list 474. All of the attributes associated with the class in the class name entry field 292 are listed in the attribute list 472. Similarly, all of the behaviors associated with the class in the class name entry field 292 are listed in the behaviors list 474. The overview tab 422 can be selected from the class editor window 290 at any time to view a particular class's attributes and behaviors. When the user has entered a new attribute, the overview window 470 will update the attribute list 472 to include the new attribute. The attribute list 472 shows the new attribute named "date". New attributes can also be entered from the overview window 470 by selecting the new attribute button 476 from the overview window 470. The user can similarly delete an attribute from the attribute list 472 by selecting the desired attribute in the attribute list 472, and then selecting the delete attribute button 478 located under the attribute list 472. When the user has entered a new behavior, the overview window 470 will update the behavior list 474 to include the new behavior. The behavior list 474 in FIG. 28 shows the behaviors currently associated with the reservation class. New behaviors can be entered by selecting the behaviors tab 426 as previously described, or they can also be entered from the overview window 470 by selecting the new behavior button 480 from the overview window 470. The user can delete a behavior from the behavior list 474 by selecting the desired behavior in the behavior list 474, and then selecting the delete behavior button 482 located under the behavior list 474. FIG. 29 illustrates the manner in which viewpoints can be saved in the 3D objects window 320. The "add viewpoint" function can be initiated by various user input mechanisms, including menu-driven input. One of the menu selections on the menu bar 142 is a view menu selection, which includes sub-menus. One sub-menu item allows the user to save a particular view in the 3D object window 320 for future reference. The user can move to any view within the 3D object window 320, and open the viewpoint name window 490 by selecting the corresponding sub-menu or by providing other appropriate user input. The viewpoint name window 490 allows the user to enter a name for the view being saved. The name entered in the viewpoint name field 492 is "In Front of SEGMENT", which is saved as the viewpoint name when the user selects the OK button 494. Saving a viewpoint name can be canceled, if desired, by selecting the cancel button 496. A saved viewpoint name is made available to the user by entering appropriate user input. In the preferred embodiment, the saved viewpoint name is added to a list of viewpoint names in a menu list. The desired view can then be seen by choosing the desired viewpoint name from the menu list. This will automatically change the view in the 3D objects window 320 to the view that was captured at the time the viewpoint name was saved. Viewpoint names can also be deleted from the list when the saved view is no longer needed. In the preferred embodiment, two default views are always available to the user, which are named the "overhead view" and the "ground view". Selection of the ground view viewpoint name from the viewpoint name menu list automatically changes the view in the 3D object window 320 to a view as seen from the plane on which the cells in the 3D object window 320 are positioned. Selection of the overhead view viewpoint name from the menu list of viewpoint names provides a view in the 3D object window 320 which is perpendicular to the plane on which the cells are positioned, or in other words, from the top of the cells. FIG. 30 illustrates an overhead view in the 3D object window 320, and further illustrates how saved views can be denoted in the 3D object window 320. The overhead view displays the class objects as seen from a vantage point above and approximately perpendicular to the plane on which the cells are positioned. Furthermore, the vantage point from which a particular view was saved can be denoted in the 3D object window 320 by selecting a "show viewpoint" function that can be initiated by various user input mechanisms, including menu-driven input. The view menu selection on the menu bar 142 in the preferred embodiment includes a menu selection item that toggles viewpoint indicators on and off. When enabled, viewpoints indicators are shown in the 3D object window 320, as is seen by viewpoint indicator 500 in FIG. 30. The viewpoint indicator 500 represents the vantage point from which the "In Front of SEGMENT" view was saved using the viewpoint name window 490 shown in FIG. 29. Referring to FIGS. 29 and 30, it can be seen that the viewpoint indicator 500 is located in a position from which the view was saved in the 3D object window 320 in FIG. 29. The viewpoint indicator 500 of the preferred embodiment is represented as a cone-shaped icon which points in the direction of the saved view from the location of the saved view. When enabled, viewpoint indicators can be seen in any view within the 3D object window 320, whether from the ground view, the overhead view, or any other view created by the user. The viewpoint indicators can also be seen as the user moves throughout the 3D object window 320 using the 3D object toolbar 324. In order for a user to move throughout the 3D object window 320, the user selects directional icons from the 3D object toolbar 324, as shown in FIG. 31. These directional icons allow the user to maneuver around the cells in the 3D object window 320 to view the three-dimensional model from any vantage point. The left arrow icon 510 dynamically changes the view as if rotating a line of sight to the left. The forward arrow icon 512 dynamically changes the view in the 3D object window 320 as if moving forward into the three-dimensional view. The right arrow icon 514 dynamically changes the view as if a line of sight was rotated to the right. The reverse arrow icon 516 changes the view to back away from the current view in the 3D object window 320. The rotate icon 518 changes the view as if the viewer were rotating around a substantially central point in the 3D object window 320. The up arrow icon 520 changes the view by raising the viewing vantage point to a higher location. The down arrow icon 522 changes the view by lowering the viewing vantage point, which can be lowered until the ground plane is reached. The cycle viewpoint icon 524 allows the user to toggle between views that have been saved using the viewpoint name window 490, as well as the default views which in the preferred embodiment include the ground view and the overhead view. Each time the cycle viewpoint icon 524 is selected, the next viewpoint is activated, and the user is taken to that view in the 3D object window 320. Referring now to FIG. 32, the capability of the OTV software tool to show the attributes in each class is shown. The "show attributes" function can be initiated by various user input mechanisms, including menu-driven input. In the preferred embodiment, the user selects a menu selection item that toggles the display of attributes on and off. The view shown in FIG. 32 displays the 3D object window 320 when the show attributes function has been toggled to the "on" position, thereby displaying the encapsulated attribute data within each cell. The outer shell of each cell becomes partially transparent, leaving each outer shell displayed as a wire frame 534. The attributes associated with each cell become visible, being displayed as an inner core of one or more stacked attribute layers surrounded by the wire frame 534 outer shell. FIG. 33 illustrates a maximized view of the flight cell 530 in the 3D object window 320 when the user elects to display attributes. As can be seen, the outer shell, or the surface walls of the flight cell 530 are transparent, and an attribute box 532 representing the stacked attribute layers within the flight cell 530 becomes visible. There are three attributes associated with the flight cell 530, including the status, condition, and schedule attributes. Any of the attributes in the attribute box 532 can be selected by clicking on the desired attribute. This allows the user to view, modify, or add attributes for the class represented by the cell, by opening of the class editor window 290 as seen in FIG. 34. The class editor window 290 automatically presents the name of the class associated with the selected attribute in the class name entry field 292. The attributes associated with the respective class are then presented in the attribute list 472 of the overview window 470. At this point, attributes and behaviors can be added or deleted as described in connection with FIGS. 26, 27 and 28. Referring now to FIG. 35, the flight cell 530 is shown having the show attributes function disabled. The outer shell of the flight cell 530 becomes visible, hiding the inner core of stacked attribute layers, and displaying one or more stacked opaque behavior layers 536. The three-dimensional flight cell 530 lists its associated behaviors on its outer shell. A "show behavior names" function can be initiated by various user input mechanisms, including menu-driven input. In the preferred embodiment, the user selects a menu selection item that toggles the display of behavior names on behavior layers 536 on and off. When the user has enabled the display of the behavior names, the outer shell displays the one or more stacked opaque behavior layers relating to the behaviors of the class corresponding to the cell. In FIG. 35, the stacked opaque behavior layers 536 display the behavior names "AddToWaitingList", "CheckStatus", "AvailableSeats", and "MatchConditions", which parallel the behavior names in the behavior list 474 of the class editor window 290 of FIG. 34. Each of these layers is labeled with the respective behavior name when the show behavior names function is enabled. When the show behavior names function is disabled, the stacked opaque behavior layers are still visible, but the behavior name labels are not visible thereon. A "collaboration" is a relationship that exits between two or more objects to fulfill the responsibility of a certain object. The process of finding collaborations between objects helps to identify the communication and relationships between objects. This is an important step in determining the points of intersection between classes, and helps to minimize the number of interactions between objects. An interaction diagram is one way to display the collaborations which occur in a given scenario. Collaborations are entered at step 200 of FIG. 5 by selecting the collaborations icon 180 in FIG. 4. Selection of the collaboration icon 180 presents the interaction diagram selection window 550 as shown in FIG. 36. A list of existing interaction diagrams will be shown in the interaction list field 552 to allow the user to select collaborations previously entered by selecting the interaction, and selecting the OK button 554. New interactions can be entered by selecting the new button 556. Selecting the new button 556 opens the new interaction diagram window 560 as shown in FIG. 37. The new interaction diagram window 560 allows the user to enter a name for the interaction diagram in the interaction diagram name field 562, and a description of the new interaction diagram in the interaction diagram description field 564. Selection of the OK button 566 on the new interaction diagram window 560 opens the interaction diagram window 570 as shown in FIG. 38. The interaction diagram window 570 of FIG. 38 allows the user to map interactions between objects to help identify the communication relationships. Collaborations between classes are created by drawing a line from one class to another class. The class labeled interface 572 is a starting point for the interaction diagram. Using a pointing device such as a mouse, a line 574 can be drawn from the interface object line 578 to the carrier object line 579 as shown in FIG. 39. Upon releasing the mouse button near the carrier object line 579 associated with the carrier class 576, the destination class window 580 for the carrier class is presented. The behaviors associated with the carrier class are listed in the behavior list field 582. Any of the behaviors in the behavior list field 582 can be selected as the behavior interaction between the interface class 572 and the carrier class 576. New behaviors can be added in the behavior list field 582 by selecting the class editor button 584 which opens the class editor window 290 as shown in FIG. 40. The new behavior can be entered in the behavior name field 452 in the behavior window 450, and a description of that new behavior can be added in the behavior description field 456. The new behavior is accepted upon selection of the OK button 296. Referring now to FIG. 41, the destination class window 580 is shown to include the new behavior in the behavior list field 582. The new behavior is then selected by highlighting the new behavior, and selecting the OK button 586. A directional interaction line 588 labeled NewBehavior is then created from the interface object line 578 to the carrier object line 579 as shown in FIG. 42. A return interaction line 590 is unlabeled because the returns field 458 in the class editor window 290 of FIG. 40 was left blank. This interaction diagram therefore includes an action called NewBehavior, and processing then returns to the interface class 572 with no return value. Additional interactions between other classes are created similarly. When the interaction labeled NewBehavior on interaction line 588 and the return interaction line 590 are created between the interface class 572 and the carrier class 576, a three-dimensional view of the interactions can be seen in the 3D object window 320. In order to show these interaction lines in the 3D object window 320, a "show interactions" function must be enabled. The show interactions function is initiated in the preferred embodiment by selecting a menu item that toggles the display of three-dimensional interactions on and off. When the show interactions function is enabled, all collaborations defined in the interaction diagram window 570 will be shown in the 3D object window 320 as three-dimensional interaction lines 592. Referring now to FIG. 43, the three-dimensional interaction lines 592 are individually shown in the 3D object window 320. The NewBehavior interaction line 588 of FIG. 42 is shown as three-dimensional NewBehavior interaction line 600, shown entering the carrier cell 602 proximate the behavior labeled NEWBEHAVIOR on the outer shell of the carrier cell 602. The 3D return interaction line 604 corresponds to the return interaction line 590 in the interaction diagram window 570 of FIG. 42, and is shown exiting the carrier cell 602 proximate the behavior labeled NEWBEHAVIOR on the outer shell of the carrier cell 602. FIG. 44 illustrates a previously defined interaction diagram in the interaction diagram window 570. This interaction diagram can be loaded in the interaction diagram window 570 by selecting the interaction diagram labeled "Book Flight" in the interaction diagram selection window 550 of FIG. 36. All interaction lines and interaction return lines can be seen in the interaction diagram window 570. The order in which the classes are presented in the interaction diagram window 570 can be modified in the interaction diagram window 570. Using a known "click and drag" method, a class can be moved to change the appearance of the interaction lines in the interaction diagram window 570. For example, in FIG. 38, the carrier class 574 is shown to the immediate right of the interface class 572. By "clicking and dragging" on the text "Carrier" associated with the carrier class 574, the text "Carrier" can be moved to the location shown in FIG. 44. In FIG. 44, the carrier class 574 is shown as the fourth class to the right of the interface class 572. The carrier class 574, along with all of its associated interactions, are redrawn at the new location. Referring now to FIG. 45, the process of creating new interactions in a pre-existing interaction diagram is shown. To create a new interaction line from the flight object line 610 to the seat object line 612 between the "MatchConditions" interaction line 614 and the "True if successful" return interaction line 616, the user clicks on the flight object line 610 and drags the mouse pointer to the seat object line 612. Releasing the mouse button proximate the seat object line 612 presents the destination class window 580 which lists all the behaviors associated with the seat class in the behavior list field 582. Any of the behaviors in the behavior list field 582 can be selected by highlighting the desired behavior and clicking on the OK button 586. If a new behavior is desired, the user may select the class editor button 584, which allows the user to add new behaviors for particular classes from the class editor window 290 as shown in FIG. 46. The class editor button 584 in the destination class window 580 of FIG. 45 can also be selected to review or amend the behavior name, the description and return value in the class editor window 290. The class editor window 290 shows the behavior name in the behavior name field 452, the description of the behavior in the behavior description field 456, and the return value in the returns field 458, from which the behavior name, the description and the return value can be modified. Referring to FIG. 47, the behavior labeled "MatchCondition" on interaction line 620 from the behavior name field 452 of FIG. 46 is shown extending from the flight object line 610 to the seat object line 612. The return value in the returns field 458 of FIG. 46 can be seen on the return interaction line 622, which shows the return value labeled "True if conditions match" from the seat object line 612 to the flight object line 610. This return value is derived from the return value entered in the returns field 458 of the class editor window 290 of FIG. 46. The interaction line 620 and the return interaction line 622 in the interaction diagram window 570 are also shown as 3D interaction line 628 and 3D interaction line 630 between the flight cell 530 and the seat cell 632 in the 3D object window 320, which is shown from the overhead view. FIG. 48 illustrates the manner in which new behaviors can be added from the destination class window 580 of FIG. 45. Where a behavior to be associated with an interaction line is not listed in the behavior field 582 of the destination class window 580, the class editor button 584 is again selected. The system then presents the class editor window 290 having the name of the class in the class name entry field 292. A new behavior can be entered as previously described by selecting the behaviors tab 426, which opens the behaviors window 450. The new behavior name is then entered into the behavior name field 452, which for the present example is labeled "IsWindowSeat". A description of the new behavior is entered into the behavior description field 456, and the return value is entered into the returns field 458. Upon selecting the OK button 296, the class editor window 290 is closed, and the destination class window 580 displays the new behavior labeled IsWindowSeat in the behavior list field 582. The user may decide to add a new behavior upon analyzing the interactions in the interaction diagram window 570. Referring to FIG. 48, the user may determine that an interaction within a single class is necessary. For instance, the user may select the seat object line 612 by clicking and releasing on the seat object line 612. This will present the destination class window 580, and the class editor window 290 can be activated as discussed above. The new behavior named "IsWindowSeat" in the behavior name field 452 is the new behavior for the interaction from the seat class 624 to itself. Referring now to FIG. 49, the destination class window 580 having the new behavior in the behavior list field 582 is shown. The new behavior labeled "IsWindowSeat" can be highlighted in the behavior list field 582. Selection of the OK button 586 when the new behavior is highlighted will enter the new behavior as an interaction from the seat class 624 to itself on seat object line 612 in the interaction diagram window 570. FIG. 50 shows the new interaction at the seat class 624 in the interaction diagram window 570. The new interaction labeled "IsWindowSeat" on interaction line 640 is shown beginning at the seat class 624 on seat object line 612, and returning to the seat object line 612. Similarly, the return value labeled "True if the seat is a window seat" on return interaction line 642 begins at the seat class 624 on seat object line 612 and returns to the seat object line 612. FIG. 50 also illustrates that the interactions in the interaction diagram window 570 are simultaneously illustrated in the 3D object window 320. The new behavior is shown in the 3D object window 320 by 3D line 644 which can be seen leaving the seat cell 632 and re-entering the seat cell 632. 3D return line 646 represents the return value that was labeled "True if the seat is a window seat". These three-dimensional interaction and interaction return lines provide the user with a clear visual representation of the interactions associated with the class. Referring now to FIG. 51, the view zoom window 650 is shown. The view zoom window 650 allows the user to change the view of the interaction diagram window 570 by "zooming" in and out. The view zoom window 650 provides fixed magnification option buttons, such as the 200% option button 652, which magnifies the standard view in the interaction diagram window 570 by two-hundred percent. The view zoom window 650 also provides a custom magnification option button 654, which provides custom zooming capabilities. For instance, in the example of FIG. 51, the custom magnification option button 654 is selected, and a custom value of "60" is entered into the custom magnification field 656. This will reduce the interaction diagram window 570 to sixty percent of the standard view size. FIG. 52 shows the interaction diagram window 570 where a custom value of "60" has been entered into the custom magnification field 656 of the view zoom window 650. Interactions between classes can be viewed individually in conjunction with the interaction diagram window 570 as described above. These interactions are shown in the 3D object window 320 so that the user can see a visual depiction of the interrelations between classes. In order to further enhance this visual depiction, the preferred embodiment of the invention provides a moving image of the interactions within the 3D object window 320. Depending on the mode of operation chosen, the interactions between cells can be viewed progressively from the first interaction to the last interaction, being analogous to a motion picture. The motion in the 3D object window 320 is a result of real-time rendering, rather than a series of previously saved images. Referring now to FIG. 53, the interaction player window 670 is shown. The interaction player window 670 can be opened through a variety of different user inputs, including menu-driven input, tool bar input, and keystroke input. In the preferred embodiment, the interaction player window 670 is activated by selecting a menu selection item. The interaction player window 670 allows the user to control the playback of interaction in the 3D object window 320. The interaction player window 670 includes control buttons for displaying the interactions in the 3D object window 320. The play button 672 starts playback of the interactions in the order they are presented in the interaction diagram window 570. The interactions in the interaction diagram window 570 will be played back in a top-to-bottom order as displayed in the interaction diagram window 570. Playback of the interactions will be delayed each time an interaction line or interaction return line reaches a three-dimensional cell in the 3D object window 320. The delay can be controlled by the user by entering the desired delay in the interaction delay field 674. The play button 672 changes to a pause button (not shown) during actual interaction playback to allow the user to pause the playback at any point. The step forward button 676 allows the user to move forward one interaction, and one interaction only, each time the step forward 676 is activated. The step back button 678 allows the user to step back one interaction, and one interaction only, each time the step back button 678 is selected. The playback rewind button 680, when selected, returns the interaction playback to the first interaction in the sequence. The detailed information option button 682 is a toggle button that enables and disables an additional display in the interaction player window 670. The detailed information option button 682 is shown in its disabled state in FIG. 53. FIG. 54 illustrates the interaction player window 670 when the detailed information option button 682 is enabled. When the detailed information option button 682 is enabled the interaction player window 670 displays the detailed information field 684. This field provides a textual representation of each of the interactions as the interactions are played back. Referring now to FIG. 55, the playback view field 686 is shown. In the preferred embodiment, three different playback views are provided: a first person view, a third person tracking view, and a third person non-tracking view. Each of these different views provide the user with a different view of the 3D object window 320 as each is seen from a different vantage point. Referring now to FIG. 56, the first person view is selected in the playback view field 686 of interaction player window 670. The information in the detailed information field 684 provides the textual equivalent of the interaction sequence set forth in the interaction diagram window 570. The interface playback begins at the interface class 572, which represents the interface to the system model. An interface cell 690 is shown in the 3D object window 320. When the play button 672 is selected in the interaction player window 670, the view within the 3D object window 320 will dynamically change to rotate from the interface cell 690 towards a recipient class which is the termination point of the first interaction. After the view has dynamically rotated towards the recipient class, which is the reservation class in the example of FIG. 56, the display within the 3D object window 320 is dynamically moved towards the reservation cell 412 as shown in FIG. 57. The rotation from the interact cell 690 and the movement towards the reservation cell 412 occurs in first person view, where the vantage point for the line of sight moves from the interface cell towards the reservation cell 412. This has the appearance of actually moving from the interface cell 690 to the reservation cell 412. A 3D interaction line 692 is shown in FIG. 57 terminating at the reservation cell 412. The 3D interaction line 692 terminates proximate its corresponding behavior name on the reservation cell 412. This corresponding behavior name on reservation cell 412 will be the same as the behavior name associated with the interaction line in the interaction diagram window 570. Referring now to FIG. 58, the first interaction is shown from the third person tracking view selected in the playback view field 686. The third person tracking view provides a view in the 3D object window 320 from a different vantage point than that of the first person view. In the third person tracking view, the user moves the cursor within the 3D object window 320 to a desired location, and the view within the 3D object window 320 is rotated about that fixed location to show each of the interactions. In other words, where the first person view gives the appearance of the user moving throughout the 3D object window 320, the third person tracking view gives the appearance of a fixed user vantage point having the view within the 3D object window 320 move and rotate about that vantage point. The fixed vantage point can be set by the user to any location within the 3D object window 320. The motion in the 3D object window 320 is the result of real-time image rendering. Referring now to FIG. 59, the third person non-tracking view is illustrated. When the third person non-tracking view is selected in the playback view field 686 of the interaction player window 670, the view in the 3D object window 320 represents a fixed view from a fixed vantage point. Therefore, the third person non-tracking view differs from the third person tracking view in that the view in the 3D object window 320 does not rotate or move about the user's fixed vantage point. Only those interactions associated with the cells currently in the 3D object window 320 will be seen. Referring now to FIG. 60, the correlation between the interaction diagram window 570, the interaction player window 670, and a three-dimensional cell in the 3D object window 320 is shown. An interaction line 700, having the behavior name "AcceptSegment" corresponds to the 3D interaction line 702 terminating at the reservation cell 412 in the 3D object window 320. The 3D interaction line 702 is shown to terminate at the behavior layer labeled "ACCEPTSEGMENT" 704. This corresponds with the interaction line 700 in the interaction diagram window 570 which terminates at the reservation object line 706 associated with the reservation class 708. The interaction player window 670 has an origin text line and a destination text line for each of the interactions which occur. The interaction origin text line 710 in the interaction player window 670 includes the text, "From: Interface::", which indicates that the origin of the particular interaction is from the interface class. The interaction destination text line 712 in the interaction player window 670 reads, "To: Reservation:: AcceptSegment". The interaction origin text line 710 and the interaction destination text line 712 will correspond to the interaction line 700 in the interaction diagram window 570, and the 3D interaction line 702 in the 3D object window 320. The information in the detailed information field 684 will continually scroll as interaction playback progresses. Referring now to FIG. 61, the interaction diagram window 570, the interaction player window 670, and the 3D object window 320 are shown after three interactions have been played back. As each interaction is played back, the interaction lines and the behavior names in the interaction diagram window 570 are preferably changed to a different color to indicate that this interaction has been played back. Furthermore, the preferred embodiment uses a single interaction line in the interaction diagram window 570, and a double line to indicate interaction return lines. Referring to the 3D object window 320, the 3D interaction lines corresponding to the three played back interactions are shown. 3D interaction line 702 is again shown originating at the interface cell 690 and terminating at the reservation cell 412. The next interaction shown is 3D interaction line 720, which originates at the reservation cell 412 and terminates at the customer cell 410. The customer cell 410 provides a return value depicted by 3D interaction return line 722 which originates at the customer cell 410 and terminates again at the reservation cell 412. In the preferred embodiment, the 3D interaction lines and the 3D interaction return lines are of different colors to allow the user to quickly distinguish between the two types of interaction lines. FIG. 62 illustrates an overhead view of multiple cells and their 3D interaction lines and 3D interaction return lines. As playback continues by way of the interaction player window 670, the 3D interaction lines and 3D interaction return lines become visible in the 3D object window 320. Referring now to FIGS. 63 and 64, the ability to modify interactions from the interaction diagram window 570 is shown. Referring first to FIG. 63, an interaction line 730 is shown in the interaction diagram window 570 from the reservation object line 706 to the customer object line 732. A three-dimensional representation of this interaction line is shown in the 3D object window 320. The corresponding 3D interaction line 734 is shown originating at the reservation cell 412 and terminating at the customer cell 410. The interaction represented by interaction line 730 can be deleted and replaced within the interaction diagram window 570, as is seen in FIG. 64. FIG. 64 shows that the interaction line 730 originating at the reservation object line 706 and terminating at the customer object line 732 of FIG. 63 as been deleted, and a new interaction line 736 is shown originating at the reservation object line 706 and terminating at the customer object line 732. The 3D interaction line 734 of FIG. 63 is therefore erased from the 3D object window 320 as shown in FIG. 64, and a new 3D interaction line 738 corresponding to the interaction line 736 is shown originating at the reservation cell 412 and terminating at the segment cell 414. Referring now to FIG. 65, the ability to move object lines in the interaction diagram window 570 is shown. By clicking and dragging the segment class 740 to the position to the immediate right of the reservation class 708, the segment object line 742 is also moved to the immediate right of the reservation object line 706. Classes can be moved within the interaction diagram window 570 to create a class order for an interaction diagram that is desirable to the user. Each interaction diagram stores its own class order, so the classes can be ordered in any manner desired by the user. It should be noted that changing the order of the classes and the interaction diagram window 570 does not affect the view in the 3D object window 320. Referring now to FIG. 66, the ability to change the sequence of the interactions in the interaction diagram window 570 is shown. The interaction line 736 and the return interaction line 744 of FIG. 66 have been moved downward in the interaction diagram window 570 which will cause those interactions to occur later in time than all interactions shown above interaction line 736 and interaction return line 744. Therefore, the user can change the time in which the interaction will occur. However, interactions that have been moved and no longer make a consistent flow of messages between classes will cause the playback to fail. In other words, a particular interaction may require that another interaction occur prior to it. If this scheduling is adversely affected, an interaction sequence error will occur, and the interaction sequence error window 750 of FIG. 67 will be displayed. This will inform the user that corrections within the interaction diagram window 570 will be required to obtain a successful interaction playback. Referring now to FIG. 68, an interaction with the customer cell 410 is shown in the 3D object window 320. The customer cell 410 includes four stacked behavior layers, one of which is the GETSEATPREF behavior layer 760. The user can delete the behavior layer 760 and its associated interactions, seen as interaction line 762 and interaction return line 764. To delete the behavior layer 760, the user selects the customer cell 410 by double-clicking on it, which presents the class editor window 290 as shown in FIG. 69. The class editor window 290 is presented having the name of the selected class in the class name entry field 292, which is "Customer" in FIG. 69. The highlighted behavior text name "GETSEATPREF" 770 is shown in the behaviors list 474. The user highlights the behavior text name in the behavior list 474 which is to be deleted, and subsequently selects the delete button 482 to delete the behavior. Deletion warning window 772 is presented upon selection of the delete button 482 to prevent inadvertent behavior deletions. The user can decide not to delete the selected behavior by selecting the cancel button 774, or can proceed with the behavior deletion by selecting the OK button 776. Where the behavior being deleted is used in existing interactions, the interaction deletion warning window 780 as shown in FIG. 70 is provided. This again provides the user with notification that deleting the desired behavior may affect various interactions. The user can decide not to delete the behavior by selecting the NO button 782, or can proceed with deleting the behavior by selecting the YES button 784. Referring now to FIG. 71, the customer cell 410 is shown after the "GETSEATPREF" behavior layer 760 has been deleted. By comparison of FIGS. 68 and 71, it can be seen that the behavior layer 760 has been deleted, and the 3D interaction line 762 and the 3D interaction return line 764 have also been erased from the 3D object window 320. Only the 3D interaction line 790 and the 3D interaction return line 792, which are associated with the "GETPREFCARRIER" behavior layer 794, remains as an interaction with the customer cell 410. The interaction diagram window 570 also provides an indication that the behavior has been deleted. The dashed interaction line 796 originating at the reservation object line 706 and terminating at the customer object line 732 indicates that the behavior "GETSEATPREF" on dashed interaction line 796 has been deleted. In the preferred embodiment, the dashed interaction line 796 is shown in a predetermined color, as well as being a dashed line, to indicate that the interaction has been deleted. Similarly, the dashed interaction return line 798 is also dashed and of a particular color to indicate to the user that the interaction return value has been deleted. The collaborations step 200 of FIG. 5 can then be exited, and the user can return to the process map window 170 of FIG. 4 by entering user input to return to the process may window 170. In the preferred embodiment, a "return to process map" menu item 799 is presented on the menu bar which can be selected by the user to return to the process map window 170. The process map window 170 of FIG. 4 can be reached from any window within the OTV software tool having the "return to process map" menu item 799. Referring now to FIG. 72, selection of the diagram states process icon 182 of FIG. 4 displays the create state diagrams window 800. The purpose of a state diagram is to provide a description of the dynamic aspect of a class, in order to increase the understanding of it. The create state diagrams window 800 provides the user with the launch flowcharting tool button 802 which, upon selection, will launch a software tool capable of creating state diagrams. After the state diagrams have been prepared, and the flowcharting tool has been exited, the create state diagrams window 800 is again presented. At this time, the user selects the done button 804 to return to the process map window 170. Selection of the encapsulation process icon 184 of FIG. 4 presents the object window 270 a | ||||||